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Preface 


This manual is one of a series designed to instruct and guide you 
in using the SPERRY UNIVAC Information Management System 
(IMS) for Operating System/3 (OS/3). It gives an overview of the 
facilities provided by IMS and how to use them. IMS Concepts 
and Facilities should be read before the other manuals in the 
series. 


This manual is divided into 13 sections, a glossary, and an index. 
The topics discussed are: 


Section 1. IMS Overview 


Introduces basic IMS concepts such as_ transaction 
processing; action programming; action programs; 
single-thread and multithread environments; and pre-online, 
online, and offline processing. Briefly discusses requirements 
for generating IMS, uses of IMS, and IMS documentation. 


Section 2. IMS Environment 


Explains how messages are processed and describes the 
interface between action programs, IMS, ICAM, and data 
management. 


Section 3. Action Programming: The Heart of IMS 
Processing 


Discusses the purpose of user-written action programs, their 
design, the action program interface with IMS, and how 
action programs process transactions. 


Section 4. Generating an Online IMS 


Discusses all phases of preparation for online processing, 
including system generation, creating a communications 
network to support IMS, pre-online processing, and IMS 
configuration. 
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Section 5. Beginning and Ending IMS Sessions 
Describes IMS start-up and termination procedures. 
Section 6. Terminal Operations and !/O Message Processing 


Describes the types of terminals supported by IMS, input 
and output messages, master and_ standard terminal 
commands, user and IMS-supplied transaction codes, and 
transaction processing from the system console. 


Section 7. File Activity with IMS 


Describes action program file processing, types of data files 
supported, record locking, IMS_ internal files, and_ file 
recovery. 


Section 8. Additional Features Available to Action Programs 


Lists and describes special features provided by IMS 
including continuous output, output-for-input queueing, line 
disconnect, snapshot dumps, UTS downline loading, screen 
format services, edit tables, and initiating an OS/3 job. 


Section 9. IMS and Distributed Data Processing 


Discusses types of remote transaction routing, configuration 
requirements, programming for distributed data processing, 
and how to process remote transactions at the terminal. 


Section 10. IMS Access to DMS Data Bases 


Describes the IMS/DMS _ interface including COBOL/DML 
action programs, data definition using a data base as a 
source, and configuration considerations. 


Section 11. Batch Processing of Transactions 

Discusses online and offline batch transaction processing, 
preparation for batch processing, input to the batch 
processor, starting up IMS for batch processing, and control 
of batch processing. 


Section 12. Defined Files and Data Definitions 


Compares conventional and defined files and describes how 
to create and access defined files. 
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Section 13. The IMS File Processing Package — UNIQUE 


Briefly describes how to use UNIQUE, the UNIQUE 
commands, and a sample UNIQUE application. 


Glossary 


Defines IMS terms used in this manual and throughout the 
IMS library. 


As one of a series, this manual is designed to guide you in 
programming and using the OS/3_ information management 
system. Depending on your need, you should also refer to the 
current version of other manuals in the series. Complete manual 
names, their ordering numbers, and a general description of their 
contents and use are as follows: 


UP-8364 


Information management system (IMS) system support 
functions user guide 


Describes the procedures to generate, initiate, and recover 
an online IMS system. 


UP-9206 


Information management system (IMS) action programming in 
RPG Il user guide 


Describes how to write action programs in RPG Il, with 
extensive examples. 


UP-9207 


Information management system (IMS) action programming in 
COBOL and basic assembly language (BAL) user guide 


Describes how to write action programs in COBOL and BAL, 
with extensive examples. 


UP-9208 
Information management system (IMS) terminal users guide 


Describes terminal operating procedures, standard and 
master terminal commands, and_ special purpose IMS 
transaction codes. Also includes UNIQUE command formats 
with brief descriptions. The manual is in easel format for 
ease of use at the terminal. 
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m UP-9209 





Information management system (IMS) data definition and 
UNIQUE user guide 


Describes how to create defined files for use with UNIQUE 
or your action programs and explains how to use UNIQUE. 
Includes extensive examples of data definitions and UNIQUE 
dialogs. 

m UP-8748 
IMS/DMS interface user guide 


Describes how to access a data base management system 
(DMS) data base from IMS. 
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INTRODUCTION TO IMS 





1. IMS Overview 


1.1. INTRODUCTION TO INFORMATION MANAGEMENT 


What is information management and what does it do? One way 
to understand this is to break it down into two words: 
information and management. 


Definition of information Information can mean many things. To you, it may mean 
information concerning your business - personnel, payroll, 
inventory, or customers - that you have on data files. Once these 
facts are on data files, you must be able to access and 

@ manipulate them. That’s where management comes in. 


Definition of management Management allows you to easily access, add, change, and 
delete data (facts) from your files so that the most up-to-date 
information about your business is right at your fingertips. And, 
because individual needs are never exactly alike, you must be 
able to tailor this management to suit your needs. 


That's where the SPERRY UNIVAC Information Management 
System (IMS) comes in. 


Characteristics of IMS 





Ww 


It's interactive. You carry on a conversation with IMS through a terminal. 


ow 


It's versatile. You tailor IMS to suit your applications. 


It's a transaction processing system. Every time you enter an input 
message, you receive a response (output message). By processing 
transactions, IMS performs the task you want it to do. 


Vv 


& It works with existing data files. They can be in two forms: conventional 
files or defined files. 
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INTRODUCTION TO IMS 








File function 











To perform a file function with IMS, just 
key in a short message at your console 
or workstation. The system sends an 
appropriate response based on_ the 
nature of your message. Thus, you have 
quick and easy access to your files 
without complex programming or the 
long wait of batch processing. 





1.2. HOW IMS REALLY WORKS 


Transaction code 


Action programs 


Processing and output 


Definition of action 


Definition of transaction 


Simple transaction 


In a very broad sense, this is what happens..., 


When you key in a message beginning with a transaction code, 
you're actually accessing one of many different programs, called 
action programs, that are known to IMS. How does IMS know 
which one you want? By the transaction code. 


All transaction codes are associated 
with an action program. Based on the 
transaction code you key in, IMS knows 
what action program to access. Then, 
the action program is processed and | 
you get some kind of response (output). aaa 
The output, of course, depends on the 
kind of action program requested. 





This entire process, from keying in a message to the completion 
of the programming function, is called an action. 


An action is the basic unit of work in IMS. 


Figure 1-1 illustrates the action process. Since the action is the 
basic unit of work, everything in IMS revolves around it. Because 
IMS is a transaction processing system, one or more actions 
comprise a transaction. 


Simple Transaction 


In some cases, One action can accomplish all the work you want 
done. When this is true, that action is called a simple 
transaction. The action shown in Figure 1-1 is an example of a 
simple transaction. 


The terminal operator keys in the transaction code BNKACT, a 
space, and an account number. The appropriate action program 
is accessed and, when it processes, it produces an output 
message that gives the account number and balance for the 
designated account. 
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INTRODUCTION TO IMS 





Dialog transaction 





ACCTNO 
52177 
BALANCE 
95.57 


ACTION 
PROGRAM 


SPECIFIES 
NORMAL 
TERMINATION 





Figure 1-1. What is an Action? 


Dialog Transaction 


In most cases, you need a sequence of two or more actions to 
complete a desired function. When this is true, the sequence of 
actions is called a dialog transaction (Figure 1-2). 


CUSTNO 12352 URRENT BALANCE = $ 112.98 


NTER PAYMENT AMOUNT $ 27.98 


ACTION 
PROGRAM 
1 


NEW BALANCE 1S $85.00 
TRANSACTION; COMPLETE 


ACTION 
PROGRAM 
2 


Figure 1-2. Example of a Dialog Transaction 


The terminal operator keys in the transaction code CUSTNO and 
a customer account number. The appropriate action program is 
accessed and, when it processes, it supplies the output message 
giving the operator the current balance for that customer's 
account. 


Action program 1 then asks for a new input message in the form 
of a payment amount for that customer. A second action 
program is accessed, and when it processes, it gives the 
operator a new balance for that customer’s account and indicates 
that the transaction is complete. 
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Function of action 
programs 


Types of action 
program 


You write action programs 
in three languages 


IMS action programs 
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Note that in a dialog transaction, the terminal operator does not 
key in another transaction code to access the second action 
program. The first action program tells IMS the name of the 
action program that will process the second message. 


Action Programs 


Now that you know about the two types of transactions (simple 
and dialog) and how to use them, let’s look at action programs. 


Action programs are appropriately named because each program 
usually performs an action. Sometimes two or more programs 
perform an action. Action programs work with IMS to enable you 
to access, retrieve, add, change, and delete data from your 
files. There are two types of action programs: 


a> Those you write yourself 





< 
Those supplied by IMS 


You can write your own action programs in one of three 
computer languages: 


Basic assembly language (BAL) 


Report program generator II (RPG Il) 





Action programs are similar to standard programs in these 
languages, but you must follow some special rules because 
action programs operate under the control of IMS. 


You can use a set of action programs provided by IMS, called 
the UNiform InQuiry Update Element (UNIQUE). These programs 
perform a variety of file retrieval and updating functions and you 
access them by special UNIQUE commands. UNIQUE is 
somewhat limited in scope; so, for most applications, you'll 
probably want to write your own action programs. 


We tell you more about writing your own action programs and 
using UNIQUE in Sections 3 and 13. 


Now that you know a little about IMS, let's look at some of the 
characteristics and common uses of IMS. 
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CHARACTERISTICS OF 





1.3. TYPES OF IMS ENVIRONMENT 


Which type to choose 


Single-thread system 


Example: single thread 


There are two types of IMS environment: 


Single-thread 


Multithread 





You decide which type you need based on your processing 
requirements and the amount of main storage you have. 


Single-thread IMS 


With single-thread IMS, only one action is processed at a time, 
but actions from different transactions may be interspersed. 


In Figure 1-3, if terminal A is using action program 1 to process 
an account, and terminal B wants to use action program 1, 
terminal B must wait until terminal A is finished before it can 
access action program 1 or any other action program. If terminal 
A comes back with another input message while terminal B is 
still using action program 1, terminal A must wait. 


TERMINAL A } TERMINAL B 
input message |: : input message 


1 INPUT QUEUE Fy 
ACTION PROGRAM 1 


OUTPUT QUEUE 


TERMINAL A 
Output message 





Figure 1-3. Single-thread IMS Operation 


IMS 





UP-9205 SPERRY UNIVAC OS/3 1-6 
IMS CONCEPTS AND FACILITIES 





CHARACTERISTICS OF IMS 








Multithread IMS 


Because actions are usually short, IMS can process transactions 
from several terminals with little delay in response time. 


Multithread system When using multithread IMS, actions are processed concurrently 
for different transactions. 


In Figure 1-4, terminals A and B each send an input message to 
action program 1. Terminal C sends an input message to action 
program 2. The input messages go into a queue which operates 
on a FIFO (first in, first out) basis. Whichever message gets there 
first is put into the queue and processed first. 


Example: multithread 


TERMINAL A TERMINAL B |) TERMINAL C 
input message input message input message 


TERMINAL A TERMINAL B TERMINAL C 
output message output message output message 





Figure 1-4. Multithread IMS Operation 
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Assume input message A in Figure 1-4 reaches the input queue 
first. IMS begins processing action program 1. When input 
message B, which also wants to use action program 1, reaches 
the queue, IMS either allows A and B to share program 1 (if 
program 1 is sharable or reentrant) or it waits until program 1 
terminates and then schedules B to use it. 


The input message from terminal C wants action program 2, and 


if enough main storage is available, terminal C’s input message is 
processed immediately. 


Now that you know the types of IMS environment, let’s look at 
what you need to generate IMS. 
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1.4. IMS SOFTWARE PACKAGE 


Software breakdown 


Processing time frames 


Prepare IMS 


Use IMS 


Recover damaged files 


Form of IMS 
components 


The IMS software package you receive contains many 
components. Not all of them are required, but because you can 
tailor IMS to your needs, you may want to include some of them. 
To understand how some of these components fit together, let's 
break IMS down into three processing time frames: 


Pre-online 


Online 


a> Offline 


Pre-online processing prepares and configures IMS to define 
your online IMS environment. 





Online processing consists of operations that process 
transactions interactively. Most of these operations are 
transparent to the applications programmer because they are 
performed within IMS. 


Offline processing consists of operations you perform after an 
IMS session. These operations include file recovery and printing 
of statistics gathered during the online session. Certain 
components of online processing make offline recovery possible. 


The pre-online and offline components are utility programs (load 
modules) that are ready to use. The online components are 
stored as source and object modules that you configure into an 
IMS tailored to your needs. 


1.5. PRE-ONLINE PROCESSING 


Pre-online components 


There are four components that function under pre-online 
processing: 


Configurator 
Named record (NAMEREC) utility 


Data definition processor 


Edit table generator 
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The most important part of pre-online processing is the 
configuration process. 


Configuration process The configurator (Figure 1-5), through the job control procedure 

creates cutom tailored IMSCONF, enables you to create an online IMS that performs the 

omMile te eyetent functions you want. IMSCONF generates and executes an IMS 
configurator program, produces and links an IMS load module 
that becomes your online IMS system, and stores it in the 
designated load library. 


Creation and contents The configurator also writes tables into the named record 

of named record file (NAMEREC) file. These tables identify transaction codes, action 
programs, and the files related to those transaction codes. This 
configuration process tailors IMS. You supply the characteristics 
of your system in the different configurator input sections. We 
tell you more about configuring IMS in Section 4. 


YOU SUPPLY 
PARAMETER INPUT 


CONFIGURATOR 
(IMSCONF) 


IMS 
LOAD 
MODULE 





Figure 1-5. Configurator Output 
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NAMEREC utility 
initializes named 
record file 


Data definition 
processor creates 
defined files 











While the NAMEREC utility has several functions, its main 
purpose is to establish the named record (NAMEREC) file (Figure 
1-6). The named record file is an internal IMS file that contains 
all tables and records needed by online IMS. These tables include 
configuration tables, data definition records, edit tables, and 
password definition tables. 





Figure 1-6. NAMEREC File 


The data definition processor enables you to create a defined 
files. Defined files are built from conventional files. They provide 
a means of creating a file for a particular application from existing 
data without having to physically create the file. Figure 1-7 
shows how the data definition processor works. 


DATA DATA 
DEFINITION DEFINITION 
SOURCE CODE PROCESSOR 


DATA 
DEFINITION 
RECORD 


LISTING OF DIAGNOSTIC 
DEFINED FILE LISTING 


Figure 1-7. Data Definition Processing 
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formats input 
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The data definition processor writes your data definitions into the 
NAMEREC file and produces a printed listing of the defined file as 
well as a diagnostic listing. 


The edit table generator (Figure 1-8) allows you to convert 
freeform input received from terminals into the fixed formats 
required by action programs. By using assorted parameters, you 
define edit tables (stored on NAMEREC as shown in Figure 1-8). 
These tables contain the characteristics of each field in your 
expected input. Based on these tables, IMS converts the input 
into usable form and checks it for types of data, value ranges, 
and the presence of required fields. 


YOU SUPPLY EDIT 
EDIT TABLE TABLE NAMEREC 


DEFINITION GENERATOR 


EDIT 
TABLES 


Figure 1-8. Edit Table Generator 


1.6. ONLINE PROCESSING 


Online components 


Function of components 


Online IMS has five main components: 


Start-up modules 
Applications management 
Internal message control 


Shutdown modules 


Action program component 





These five components are transparent to the applications 
programmer and function internally to process transactions 
interactively (Figure 1-9). We mention them here because, based 
on parameters you designate at configuration time, you have 
some control over how they process transactions. As a result of 
configuration, these components become part of the IMS load 
module. 


UP-9205 


IMS SOFTWARE AND PROCESSING 


Start-up modules initialize 
online functions 


Applications management 
has two parts 


Action scheduling 


File management 
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START-UP 


APPLICATIONS MANAGEMENT 


J) 


ACTION FILE 
SCHEDULING MANAGEMENT 


VY 


DEFINED RECORD 
MANAGEMENT 


INTERNAL MESSAGE CONTROL 


SHUTDOWN 


ACTION PROGRAM COMPONENT 
PROCESSES 


R 


IMS-SUPPLIED 
(INCLUDES UNIQUE) 





Figure 1-9. IMS Load Module 


Start-up modules initialize functions needed for online operations. 
This process is transparent to you but you have some control 
over it by using optional start-up parameters when you execute 
the IMS load module. We tell you more about this in Section 4. 


The IMS applications management component is_ also 


transparent, but it plays an integral part in handling transactions. 
It has two parts: 








Action scheduling 


> File management 


Action scheduling schedules an action for each input message by 
allocating main storage and other resources needed by that 
action. It also handles termination of action programs. 


File management (Figure 1-10) provides all action program 1/O 


functions and provides access to your data files through OS/3 
data management. 
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Files types used with 
file management 


IMS internal files 


Your data files 


Defined record 
management 


Bee ING 


ACTION LOGICA LOGICAL PHYSICAL 


PROGRAM RECORDS RECORDS RECORDS 





Figure 1-10. How IMS Accesses Your Data Files 


File management interfaces with two types of files: 


IMS internal files 


Your data files 





The IMS internal files are: 


Vv vv vv Vv VY 


Named record file (NAMEREC) 

Continuity data file (CONDATA - multithread only) 

Audit and continuity data file (AUDCONF - single-thread only) 
Audit file (AUDFILE - multithread only) 

Trace file (TRCFILE) 

Terminal output message file (TOMFILE) 

Statistical data file (GSTATFIL) 


Fast loader file (LDPFIL) 


We tell you more about these files in Section 7. 


File management controls access to your data files and performs 
file and record locking functions. The locking capabilities are an 
IMS feature that guards against concurrent updating of the same 
data by multiple actions. 


Defined record management, a subcomponent of _ file 
management, accesses defined files. 
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Internal message control 


Action program component 


IMS-supplied programs 


User written action 
programs 


The internal message control component: 


Sed 


Keeps track of your messages 
Processes input and output messages 
Executes terminal commands 


Controls message editing 


Vv VV VW 


Provides an output message when your transaction ends 
without one 


The action program component of online IMS handles the 
processing of two kinds of action programs: 


IMS-supplied action programs 


User-written action programs 





The IMS action programs consist of UNIQUE and_ other 
IMS-supplied action programs. We talk more about UNIQUE in 
Section 13 and other IMS-supplied programs in Section 6. 


The handling of your action program involves the activation 
record (3.6) and an action program load module, which consists 
of your source program (written in COBOL, RPG II, or BAL) linked 
to an IMS interface module. 


1.7. OFFLINE PROCESSING 


Offline components 


Offline recovery utility 
used when online 
recovery fails 


There are three utility programs available with offline processing: 


The offline recovery utility 


The tape copy program 


The statistical file print program 





The offline recovery utility reconstructs your files when online 
recovery fails or cannot correct the problem. You determine the 
type of offline recovery you want at configuration time. 
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Tape copy program A tape copy program recovers a tape trace file that is left open 
Patera ae mee as the result of a system failure. This program then produces a 


new trace file (containing the open file’s contents) that you can 
use for offline recovery. 


Statistical file The statistical print program prints statistics recorded during the 
lk ha online IMS session. 


Now that you're familiar with IMS components, let’s look at what 
you need to generate an online IMS. 
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1.8. WHAT YOU NEED TO GENERATE ONLINE IMS 


System generation 


ICAM generation 


User written action 
program compilation 


When you operate any system, there are assorted system 
operations you perform to get various system functions. These 
operations are performed at various times in the processing 
environment. Some are external to IMS (which we call system 
requirements) and others are part of IMS software (which we call 
IMS requirements). 


System Requirements 


To prepare OS/3 to support online IMS 





First, generate an OS/3 operating system to support online IMS. This is 
done in a process called system generation (SYSGEN). There are three 
phases of SYSGEN you are concerned with when generating IMS. They 
are the SUPGEN, the RESGEN (Series 90 only), and the COMMCT phases. 
System generation is discussed in Section 4. 


Second, because online IMS functions as part of a communications 
system, generate an integrated communications access method (ICAM) 
symbiont that supports your IMS. You do this in the COMMCT phase of 
system generation. Generating an ICAM symbiont involves defining a 
communications network for the transaction control interface (TCI), which 
is the only communications interface that supports IMS. See the ICAM 
network definition manual for information on ICAM generation. 


Finally, compile or assemble any user written action programs. 





Now that you've taken care of the external system operations, 
we will look at the IMS operations you must perform to ready 
your system for online processing. 


IMS Requirements 

In 1.4, we cover the components of IMS and the processing time 
frames in which each occur. The IMS functions needed to 
prepare online IMS are performed in the pre-online processing 
time frame. They are: 


Initialize the NAMEREC file 


> Configure IMS 
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Initialize the 
NAMEREC file 


Configure IMS 


1.9. USES OF IMS 


Common applications 


Additional applications 
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You must initialize the NAMEREC file before any other pre-online 
processing can take place because all of the IMS processors, 
including the configurator, contribute to this file. 


There are two ways to initialize the NAMEREC file: 


Using the NAMEREC utility (ZP#NRU) 


Using the INIT parameter of the IMSCONF 
job control procedure during configuration 





We tell you more about initializing NAMEREC in Section 4. 


Configuring IMS is also a required step. The configuration 
process initializes IMS internal files and generates your online IMS 
system. Configuration allows you to tailor IMS to fit your needs. 
Configuring your system is described in Section 3. 


Now that you know the system and IMS requirements to create 
an online IMS, let’s look at some of the common uses of IMS 
and other documentation you need for smooth operation of your 
system. 


Here are some of the IMS applications. 





Order entry 


vy 


Accounts payable 


Accounts receivable 


> 
b 


Payroll 





Other uses of IMS are: 


Inventory control 


Vv 


General ledger 


Publications subscriptions 


Vv 
vy 


Manufacturing 


Medical records 


4 


Cost accounting 


Tax records 


Vv Vv 
Vv 


Sales inventory 
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1.10. IMS DOCUMENTATION 


In addition to this manual, you'll need to reference these other 
IMS manuals: 


This manual helps you 
learn about IMS by 
explaining concepts and 
providing general back- 
ground information about 
IMS and action pro- 
gramming. 


NOTE: 
YOU MUST READ 
UP-9205 TO UNDER- 
STAND THE OTHER 
IMS MANUALS. ALL 
IMS MANUALS OTHER 
THAN UP-9205 ARE 
HOW-TO MANUALS 
AND CONTAIN A 
MINIMUM OF THEORY. 





To prepare and generate 
your own IMS system, 
and understand offline 
processing, you'll need 
this manual 


If you want to use 
UNIQUE, go to this 


action programs go to Y manual; which also tells 
these manuals <> you how to use defined 


files 





Then, to write your own 






Then, when you're ready There is an IMS interface 

to run IMS, this manual e that lets you access a DMS 
tells you how to use the |. IMs “ data base from {MS action 
terminals, terminal Terminay Se programs. This manual 
commands and IMS- 0 : describes that interface and 
supplied action programs. tells you how to use tt 
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eo... OTHER HELPFUL DOCUMENTATION 


To aid you in essential non-IMS functions, you may find the 
following manuals helpful. 


> To generate your OS/3 operating system to support IMS, you'll need one 
of these manuals: 





> Then, to generate your communciations network to support IMS, you'll 


& need the following ICAM manuals: 


First... Then... 





This manual tells you about This manual has the macro- 

ICAM and its requirements instructions and commands 
used to define the communica- 
tions network and create the 
{CAM symbiont 











UP-9205 SPERRY UNIVAC OS/3 2-1 
IMS CONCEPTS AND FACILITIES 


IMS MESSAGE FLOW 


2. IMS ENVIRONMENT 


2.1. BUILDING AN IMPRESSION OF IMS 


Scope of section Up to this point, we have skimmed over some of the IMS 
terminology. In this section, we get more specific and tell you 
about the IMS environment. As you read this section, you will 
come across many new terms, which up to this point we may 
not have mentioned. Don't try to understand each new term fully 
at first; simply concern yourself with the concept being 
presented. We provide the details in later sections. For now, 
concentrate on how IMS functions within its environment. 


2.2. IMS — THE FIRST IMPRESSION 


Computer environmments Ail computer systems operate in environments. The word 
environment = simply means surroundings. A computer 
environment generally includes all hardware and software that a 
system needs to operate. Within an environment, there also 
exists hardware or software that is not needed for the basic 
operation of the system, but is needed for specific applications. 
The same is true with IMS. 


IMS has many parts; some required, some optional. To help you 
build an impression of IMS, we start with a simple diagram, and 
then build on it to encompass a possible IMS environment (Figure 
2-1). 


INPUT 
MESSAGE 


ACTION 
& PROGRAM 


Figure 2-1. Simple Representation of IMS Flow 
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What is ICAM? 


Your input message, like most IMS messages, is sent from the 
terminal. It is then passed by ICAM to IMS. 


IMS interprets your input message, processes the requested 
action program, and passes an output message back through 
ICAM, to your terminal. 


Based on what you already know about IMS, the terms in Figure 
2-1 (except ICAM) should be familiar to you. The acronym ICAM 
stands for the Integrated Communications Access Method. 


ICAM is the communications software that handles all input and 
output between your terminals and IMS. To do this, it must 
know how many and what kind of terminals you have and what 
your needs are. You tell this to ICAM by defining an ICAM 
network. We tell you more about ICAM network definition in 
Section 4. 


Now that you've seen the basic IMS flow, let's expand on each 
of the components of Figure 2-1 so you can see what's really 
involved. 


2.3. AN EXPANDED VIEW 


Message passage 


Communications adapter 
connects terminals to 
ICAM 


In Figure 2-1, ICAM is shown as an empty box, mysteriously 
passing messages back and forth. The lines on which your 
messages travel seem to go directly from your terminal to ICAM. 
This is really not so. Figure 2-2 adds another box, the 
communications adapter (Series 90) or the single line 
communications adapter (System 80). To eliminate confusion, 
regardless of your system, we refer to it simply as_ the 
communications adapter. The communications adapter is a 
piece of hardware; ICAM is software. 


INPUT 
MESSAGE 


COMMUNICATIONS 
ADAPTER 





Figure 2-2. How Your Terminals are Connected to ICAM 
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@ rocstin The communications adapter controls and coordinates data 
adapter function transfers, status, and commands between ICAM and_ your 
terminals. It, in effect, polices the message flow so that your 

system can operate efficiently. 


Inside ICAM 


Let’s look at what happens in ICAM when your terminal sends an 
input message (Figure 2-3). 


INPUT 


COMMUNI 
MESSAGE OM CATIONS 


ADAPTER 


LINE BUFFERS 


r--c-- ee 


ICAM 
q PROCESSING 
eed macs 
NETWORK 
BUFFERS 





Figure 2-3. What Happens Inside ICAM? 


First, your message passes through the communications adapter. 
When ICAM receives the message from the communications 
adapter, it goes into an ICAM line buffer. Line buffers temporarily 
hold messages until ICAM can process them. 


ICAM does the internal message handling, places the message in 
an ICAM network buffer for passage to IMS. ICAM stores the 
input message in main storage until IMS is ready for it. 


Inside IMS 
Inside IMS Let's expand our diagram even more. Up to this point, IMS is 
shown as an empty box that processes your input messages. 
& Let’s take a look inside and see what really happens. 
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IMS MESSAGE FLOW 


IMS is a program 


Action programs are 
subprograms to IMS 


Message passage to IMS 


IMS processing 
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First of all, although IMS appears to be a separate entity, it really 
is a program (called a communications user program) that 
functions as part of the communications network. The action 
programs you write are actually subprograms within the IMS 
program. Look at Figure 2-4 to see inside IMS. 


INPUT 
MESSAGE 
BUFFERS 


ACTIVATION 
RECORD 


ACTION 
PROGRAM 





Figure 2-4. Inside IMS 


When ICAM has a message for IMS, it passes the message into 
an input message buffer within IMS. You designate the size of 
this input buffer when you configure your IMS. Among the things 
included in this message is the transaction code for the action 
program you want to access. 


IMS, using its online components (described in 1.4), processes 
the message. IMS: 


reads the transaction code; 


checks the NAMEREC tables (in main storage) to find the action 
program and files that are assigned to the action; and 


assigns an activation record for the action. 
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: Function of NAMEREC 


& Until now, all we've mentioned about NAMEREC is that it’s an 
ve 


IMS internal file that contains records from all other parts of IMS. 
Included in this NAMEREC file, we said, are tables from the 
configuration process. These tables, among other things, tell IMS 
the names of all your transaction codes, the names of the action 
programs related to that transaction code, and the names of the 
files related to each action. 


The contents of the NAMEREC file are read into main storage 
during IMS start-up. When IMS needs information from these 
tables, it goes to the main storage area where these tables now 
reside. 


Also during processing, an activation record is assigned for the 
action program. 


Activation record The activation record is a main storage interface area that 

definition contains and passes control information and data between your 
program and IMS. An activation record can contain as many as 

Parts of the activation six parts: 

record 





Program information block (PIB) 


Input message area (IMA) 
Output message area (OMA) 
Work area (WA) 


Continuity data area (CDA) 


Defined record area (DRA) 





Required parts 5 . : 
: Two parts are always required — the program information block 


and the input message area. The output message area is not 
required but is almost always used. The other parts depend on 
which programming language you're using and the needs of the 
individual action program. 


We talk more about the activation record and its function in 
Section 3. 


But, back to Figure 2-4 ..... 


The input message is written into the input message area (IMA) 
Input message area ; ‘ . . 
& of the activation record to await transfer to the action program. 
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Output 


Program to file interface 
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Then, the action program accesses your data files and processes 
the data. If you don’t have an output message area, no message 
can be sent from your completed action program to your 
terminal, so IMS sends a message saying TRANSACTION 
COMPLETE. (This message is sent from the internal message 
control component of online processing). Normally you would 
provide an output message. It’s only when you do not, that IMS 
sends this message. 


To expand a little on Figure 2-4, your action programs do not 
actually interface directly with your data files, they use the file 
management component of IMS and OS/3 data management. 
Figure 2-5 shows what happens when an action program 
requests a record. The process is similar for writing a record. 
Data management receives the logical record from IMS file 
management and writes it into your data file.. 


ACTION LOGICAL PHYSICAL 


L 
PROGRAM RECORDS # RECORDS RECORDS 


Figure 2-5. How Your Action Programs Interface with Your Data Files 
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THE OVERALL PICTURE 


2.4. 


, let's look 


into its parts 


2-6) so you can see how 


Now that you've seen IMS broken down 


its 


Il f 


it a 


igure 


(F 


at the whole picture 


together 


COMMUNICATIONS 


ADAPTER 


ICAM 
PROCESSING 





Se 


ee 





IMS - The Big Picture 


Figure 2-6. 
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3. Action Programming: 
The Heart of IMS Processing 


3.1. PURPOSE AND TYPES OF ACTION PROGRAMS 


Function of Action programs are the heart of IMS. Without them you can't 

Action programs process messages. The main purpose of an action program is to 
process input messages and generate output messages. But they 
also perform file retrieval and updating functions. 


As you know, there are two kinds of action programs: 









Type of action : <>, ; 

pricier || > Those that IMS supplies 
> Those you write yourself 

IMS supplied One set of action programs that IMS supplies is the Uniform 

action programs Inquiry Update Element (UNIQUE). UNIQUE is a set of programs 
that performs file retrieval and updating functions. UNIQUE 
functions are initiated by UNIQUE commands. When you use 
UNIQUE, you do not need to write your own action programs. 
(UNIQUE is discussed in Section 13. Other IMS-supplied action 
programs are discussed in Section 6.) 

User written This section concentrates on the action programs you write 

Action programs yourself; how they're set up, and how they are processed. You 


can write action programs in COBOL, basic assembly language 
(BAL), and RPG Il. We do not go into much detail about the 
specifics of these languages. Rather, we present general 
concepts of action programming. If you want information on how 
to write action programs in these languages, see IMS action 
programming in COBOL and BAL user guide, UP-9207, or IMS 
action programming in RPG Il user guide, UP-9206. 








UP-9205 
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3.2. WHY WRITE YOUR OWN ACTION PROGRAMS 


Limitations 


Custom-tailoring 
action programs 


UNIQUE is an easy-to-use file retrieval and updating system. So 
why, if UNIQUE is so easy to use, should you write your own 
action programs? Because UNIQUE, like many packaged 
programs, is limited in how much it can do. And, you may want 
to use IMS in ways not possible with UNIQUE. 





b Update files that require extensive data validation 
Use special output formats 


Perform calculations on your data 





When you write your own action programs, you design them to 
fit your needs. If your application requires validation of all 
terminal input, you code that into the program. If you want to 
perform calculations on terminal input and update your data files 
on the basis of these calculations, you code that into your 
program also. 


If you want output messages to appear in a particular way on the 
terminal screen, you provide the format in your action program. If 
there are special messages or prompts you want to give the 
terminal operator, you can also code them into the program. You 
can also use screen format services to format output messages. 


3.3. DESIGNING AN ACTION PROGRAM 


What makes action 
programs different 


Keep action programs 
simple 


Actually, action programs are not that different from any other 
program. They handle all the file processing activities your regular 
programs currently handle. What is different is that they handle 
them in an interactive environment by carrying on a conversation 
with the terminal operator. 


Since action programs carry on a conversation with a terminal 
operator, the most important thing to remember when designing 
an action program is to keep it simple. Present the data that the 
program requests, and the answers or output it will provide, in a 
clear and concise way so that it can be easily understood by the 
terminal operator. 
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Maintaining efficiency Also, action programs operate most 
efficiently when they perform short, 
precise tasks. When you converse with 
someone, you do not listen to their 
question and then leave them ‘“‘hanging’’ 
for an answer. 





Provide constant 


Terminal operators should get almost 
feedback to the operator 


constant feedback to their inquiries. 
Design the action program to take the 
Operator's inquiry, process it, and 
provide a quick and _ appropriate 
response. Then, the program requests 
more data from the operator. This 
process continues for as long as 
necessary, but the key is that the 
operator is never stranded. The action 
program keeps the conversation going. 








UP-9205 





SPERRY UNIVAC OS/3 3-4 
IMS CONCEPTS AND FACILITIES 


IMS HANDLING OF ACTION PROGRAMS 


3.4. HOW IMS SUPPORTS ACTION PROGRAMS 


IMS/action program 
relationship 


IMS‘s supporting role 


IMS handles message I/O 


IMS handles file I/O 


Activation record handles 
communication between 
IMS and action programs 


You already know that the major activity of action programs is 
processing input messages and producing output messages. To 
understand what this involves, there is something much more 
fundamental that you must understand first. 


You must understand that IMS is itself a program. The action 
programs you write operate as subprograms of IMS. What does 
this mean= It means that IMS and action programs share a 
special relationship. They work as a team. 


Because of this relationship, there are many things that action 
programs depend on IMS to do for them. For instance, action 
programs don't handle 1!/O. The internal message control 
component of IMS handles all input messages coming into the 
program and all output messages generated by the program. 


File I/O is performed by the file management component of IMS. 
Action programs direct all file |/O functions to IMS which, in turn, 
passes them on to OS/3 data management. 


This relationship between IMS and action programs demands a 
lot of communication. That's why action programs must set up 
an area where this communication takes place. We've mentioned 
this area before. We talk about it more in this section. It's called 
the activation record. All communication between IMS and the 
action program passes through the activation record. 


ACTIVATION Ey ACTION 


RECORD ES PROGRAM 





The Activation Record Interfaces IMS to Action Programs 
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3.5. CONTENTS OF THE ACTIVATION RECORD 


The activation record can contain up to six areas. These areas 
are the program information block, the input and output message 
areas, the work area, the continuity data area, and the defined 
record area. 


The program information block passes control information 
between IMS and your action program during program 
processing. This information is very valuable to an action 
programmer. For instance, after each |/O file request made to 
IMS, certain fields in the program information block contain the 
results of that request. 





The action program can examine these fields to determine if the 
request was successful or not. The program information block 
also contains the accurate calendar date and clock time. 
Programmers often want to make this data part of an output 
message. 


The input message area receives input from the terminal. The 
input message remains here until the action program is ready to 
process it. 


The output message area holds the output message that the 
action program generates. 


COBOL and BAL use the work area to hold logical records during 
file processing and as a working storage area. 





RPG Il action programs never actually use the work area; 
however, the compiler does for certain applications. 


The continuity data area holds data that an action program wants 
to save and pass to the action program that follows it (successor 
program). When the first program finishes processing, IMS stores 
the saved data until the successor program is scheduled. Then, 
IMS makes the saved data available to the successor program. 





The defined record area is used by defined record management 
when action programs use defined records. Action programs 
cannot access this area. 
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3.6. SETTING UP THE ACTIVATION RECORD 


Determining activation 
record needs 


Loading activation 
record ; 


Every action program must define an activation record. It is 
coded as part of the action program. How many areas the 
activation record contains depend upon the needs of the 
application. Define only those areas you need. For instance, most 
action programs begin processing by receiving an input message 
from the terminal. There must be an area to receive that 
message. So, the action program must define an input message 
area as part of its activation record. 


On the other hand, if the program do not pass data to a 
successor program, then don’t define a continuity data area. 
Define only those areas you need. 


Each time a terminal requests an action program, IMS schedules 
it and loads it in main storage. IMS also loads the activation 
record set up for that program. Once the program begins 
executing, the data that IMS and the program exchange is stored 
in the activation record. 
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3.7. CODING ACTION PROGRAMS 


Types of coding 


Efficient code 


Configuration 
requirements 


Using serially reusable 
code 


Example 





When writing your own action programs, there are three types of 
coding you can use: 


> Serially reusable 


Reentrant 







The type of coding you use depends on the programming 
language you're using. The most efficient way to code an action 
program is to make the code reentrant or shared, but this is not 
always possible. You designate the type of coding you're using 
at configuration time. You do this with the TYPE parameter in 
the PROGRAM section of the configuration. 


With serially reusable code, only one user can access the 
program at a time. Another terminal requesting the same 
program must wait until the first user is finished. 


Figure 3-1 shows terminals A and B both requesting action 
program PROG1. The first terminal to request the program (in this 
case, terminal A) gets access to the program. Terminal B must 
wait until terminal A finishes processing. 


INPUT QUEUE 


SERIALL Y-REUSABLE 
CODE 


PROG1 


Figure 3-1. Action Program Written in Serially Reusable Code 
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Efficiency considerations 


When serially reusable 
code must be used 


Coding requirements 


' Using reentrant code 


Reentrant code shareable 


Restrictions on using 
reentrant code 





In a multithread IMS, if there is sufficient space, serially reusable 
programs reside in main storage. This way they do not have to 
be reloaded each time they're requested. A single-thread IMS will 
keep the program loaded only if used by the next input. 


Serially reusable code is used most efficiently in a single-thread 
environment where you process only one action at a time; but 
this is also permitted in a multithread environment. All action 
programs can be written in serially reusable code; however, RPG 
il programs must be since they cannot function as reentrant or 
shared. 


With serially reusable code, you must reset all fields to their 
original values at the end of the program so that the program is 
ready for the next user. 


With reentrant code (Figure 3-2), the action program is loaded 
into main storage and can be used concurrently by two or more 
users. 


Reentrant programs are completely shareable. Thus, no parts of 
the program can change during action processing because more 
than one action is using the program. BAL action programs are 
the only type of program where you use reentrant code. 


INPUT QUEUE 


REENTRANT 
CODE 


PROG2 


Figure 3-2. Action Program Written in Reentrant Code 
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Using shared code Shared code programs (Figure 3-3) are the same as reentrant 
code programs except that, instead of being completely 
ae ; shareable, they're only partially shareable. With shared code, 
Restrictions on using d ‘ . ; 
eharad code each user has its own activation record. COBOL action programs 
are the only type of action programs that use shared code. 


A shared code parameter in the COBOL compiler lets you 
designate the program as shareable. When you use shared code 
in a COBOL program, only the procedure division and the 
working storage sections are shareable (Figure 3-3). 


SHARED CODE ' 





Figure 3-3. Action Program Written in Shared Code 
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Entering the transaction 
code 


Input staging buffer 


3.8. HOW ACTION PROGRAMS ARE PROCESSED 
IMS transactions begin when the terminal operator enters a 


transaction code at a terminal. Once that transaction code — the 
first input message - is transmitted, things begin to happen. 


TRANSACTION 


ACCOUNT NUMBER 





Assume the terminal operator enters the transaction code 
CUSTNO and a customer account number as input. Initially, IMS 
is only interested in transaction codes. Transaction codes are 
from 1 to 8 characters in length in multithread IMS and 1 to 5 
characters in single-thread IMS. This code comes into the IMS 
input staging buffer. Messages are queued at the staging buffer 
until IMS can handle them.. 


IMS 
CUSTNO 12345 INPUT STAGING 


BUFFER 





As soon as IMS receives the transaction code (CUSTNO), it 
validates it by looking at the transaction code table. This table 
lists all the transaction codes that this IMS _ configuration 
supports. 
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ACCTNO 
CUSTNO 


LACCT 
ORDR 
7123 
TRN1 





If IMS doesn’t find CUSTNO, an error message is sent to the 
terminal. If it is a valid transaction code, IMS processes the input 
message. 


Getting the action name The transaction code table also provides the next piece of data 
IMS needs - the name of the first program that processes this 
transaction. In this case, the name of the first program is also 
the name of the first action in the transaction. IMS now goes to 
another table - the action control table - to get more detailed 
data about this action. 


e The action control table is stored in the named record file at 
configuration time and is loaded into main storage at start-up. 

Using the action The action control table tells IMS what it needs to know about 

control table the action program or programs that process this action. For 


instance, the action control table describes all the files used in 
processing the action and the size of the largest output message 
it can produce. 
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Using the program 
control table 








TRANSACTION 
CODE ACCTNO f DATA ABOUT 
EACH ACTION 

IN THE 


TRANSACTION 


DATA ABOUT 
EACH PROGRAM 
IN THE 
ACTION 


In multithread IMS, the action control table tells how many users 
can process an action concurrently. One of the most important 
pieces of data it contains is the size of the largest nonresident 
program in this action. 


When IMS gathers all the data it needs, the action control table 
directs IMS to the program control table. (It is also generated 
during the configuration process and is part of NAMEREC). The 
program control table tells IMS about the specific program or 
programs processing this action and contains data about whether 
the program is serially reusable, shared, or reentrant, and 
whether the program permanently resides in main storage. 


RESOURCES FOR 
TRANSACTION CUSTNO |” 
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Assessing IMS resources (While IMS moves from table to table, it’s assessing the needs of 
the action program or programs requested by the transaction 
code CUSTNO and comparing those needs to the resources 
available. IMS checks that: 


required files are available; 

there is sufficient main storage for: 
~  1/O areas 
- action program 
- activation record 


Scheduling the If any of the action program's needs cannnot be met, the 

action program transaction code remains in queue until all resources are 
available. When the resources are available, IMS schedules the 
first action program to process the transaction and loads it in 
main storage (unless, of course, it is already there). In addition, 
IMS allocates and initializes the action program’s activation 
record. 


3.9. TRANSACTIONS, TERMINATIONS, AND SUCCESSION 


Before we consider the next series of steps in processing an 
action program, there are some basic concepts and terminology 
you should become familiar with. A few of these terms are noted 
elsewhere. Here, we review them quickly and then introduce a 
few new terms. 


The ‘action’ As we told you in 1.2, the action is the basic unit of work in 
IMS. An action occurs when you key in an input message, the 
appropriate program processes it and a programming function 
(e.g., data retrieval) is completed, and a response or output 
message is sent back to the terminal. Figure 3-4 shows an 
action. 





© PROCESSING : OUTPUT 


Figure 3-4. An IMS Action Always Consists of Three Parts 
(Input, Processing, and Output) 
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The ‘transaction’ 


A simple transaction 


A dialog transaction 


Transaction structures 


‘Termination type’ 





Generally, one action program performs one action. Sometimes 


more than one action program is needed to complete the action. 


A transaction refers to the whole task you want accomplished. 
They consist of one or more actions. When one action can 
accomplish all your processing needs, it’s a simple transaction. 
In this case, action and transaction are synonymous. 


ACTION 
PROGRAM 





A Simple Transaction Process (One Action Only} 


Often, a sequence of two or more actions is needed to 
accomplish your processing; this is called a dialog transaction. 
Dialog transactions process more than one action program. 


ACTION ACTION 
PROGRAM 
1 


ACTION 
PROGRAM 
2 


A Dialog Transaction Processes Two or More Actions 


These two types of transactions, simple and dialog, are called 
transaction structures. They provide flexibility in designing 
action programs. In 3.5 we mentioned that action programs can 
be linked together. This happens by using transaction structures. 


You set up the type of transaction structure you want by 
specifiying a termination type. What this means is that you 
send IMS, right within your action program, a message. This 
message tells IMS whether you’ve completed your task or 
whether more processing is needed. This message allows IMS to 
create the transaction structure you need. 
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3.10. TERMINATION TYPES 
There are four termination types used to structure transactions: 


Types of termination Normal termination 


External succession 


Delayed internal succession 


Immediate internal succession 





MORE processing All four of the termination types tell IMS that the current program 
is finished processing. Types 2, 3, and 4 tell IMS that more 
processing follows. 


When you specify normal termination, you're telling IMS that the 
NO MORE processing transaction is complete. No more processing will occur. Every 
transaction ultimately ends with normal termination. 


Another program follows When you specify external, delayed, or immediate succession, 
you're telling IMS that another action program will follow and 
resume processing. 


Figures 3-5 to 3-8 show how each termination type is used in 
action program processing. 





Normal termination tells IMS all processing is complete. You can 
specify normal termination after a single action program has 
finished executing or after a series of action programs have 
completed processing. It all depends upon how you want to 
structure your transaction. 


Using normal termination 


ACTION 
PROGRAM 
INPUT ee OUTPUT 


SPECIFIES 
MESSAGE 
usa = NORMAL 


TERMINATION 





Figure 3-5. Transaction Structure Using Normal Termination 
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Using external 
succession 





External succession tells IMS that the current program is finished 
processing but there is still more to be done. A successor 
program follows to pick up where the first program left off. 


With external succession, the first action program processes an 
input message and produces an output message; and so does 
the successor program. There are two sets of input and output, 
or in other words, two separate actions. 


IMS doesn’t schedule the successor program until it receives the 
second input message. Figure 3-6 shows the sequence of 
activities when you specify external succession as the termination 


type. 


INPUT ACTION OUTPUT 
MESSAGE PROGRAM MESSAGE 
1 1 1 


INPUT ACTION OUTPUT 
MESSAGE PROGRAM MESSAGE 
2 2 2 





Figure 3-6. Transaction Structure Using External Succession 
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Using delayed internal Delayed internal succession (Figure 3-7) tells IMS that the current 

succession program is finished processing but there is more processing to 
follow. The successor program picks up where the previous 
program left off. 


With delayed succession, the first program processes an input 
message and produces an output message; but, the output 
message does not go to the terminal. The terminal operator 
never sees it. Instead, when the first program finishes 
processing, IMS takes the output generated and passes it as 
input to the successor program. 


The successor then processes that input and produces an output 
message which goes to the terminal. Even though only the first 
input message and the second output message are actually seen 
at the terminal, internally there are two separate input and output 
messages and, consequently, two separate actions. 


OUTPUT 
& MESSAGE PROGRAM MESSAGE 
1 1 


OUTPUT MESSAGE ACTION OUTPUT 


1 QUEUED AS PROGRAM MESSAGE 
INPUT MESSAGE 2 > 


2 





Figure 3-7. Transaction Structure Using Delayed Internal Succession 
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Using immediate Immediate internal succession, like external and delayed internal 

succession successions, also says the current program is completed and a 
successor will follow. In this type of termination, there is an 
initial input message. 


The first action program processes the message and the second 
program is immediately scheduled to continue the processing. 
When the second program finishes processing, it generates an 
output message and terminates. 


In immediate internal succession, therefore, there is only one 
input and one output message. Consequently, there is only one 
action. Figure 3-8 shows a transaction structure using immediate 
internal succession. 


ACTION ACTION U 
PROGRAM PROGRAM MESSAGE 
1 2 1 





Figure 3-8. Transaction Structure Using Immediate Internal Succession 


As you can see, these four termination types allow a great deal 
of flexibility. Soon we will see how this flexibility is put to use. 


3.11. SPECIFYING TERMINATION TYPE AND NAMING SUCCESSOR PROGRAM 


Specifying termination You specify termination type within your action program. In this 

type way, you inform IMS of the transaction structure you're creating. 
The only time you don’t need to specify a termination type is 
with normal termination. When you don't specify otherwise, IMS 
assumes normal termination. 


Defining a program To specify the termination type, you must set up a program 
information block information block area in your activation record. During 

processing, the action program moves a termination code to the 
Using the termination- termination-indicator field of the program information block. This 


indicator field code tells IMS how you want to structure your transaction. 
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Codes used N Normal termination {if you don't specify a code, IMS assumes normal 
termination) 


E External succession 


D Delayed internal succession 


I Immediate internal succession 





Naming a successor For termination code E, D, or |, you must name the successor 
program program. You enter the name in the successor-id field of the 
program information block. The name can be 1 to 6 characters 


Using the successor-id : et : : ; 
field long and identifies the program that will continue processing the 


transaction. 


A transaction code is not required in the second (or subsequent) 

input messages of a transaction since the ‘successor-id’ specified 

by the previous action program names the program that will 
@ process the next message. 


Examples Figure 3-9 illustrates moving the termination code and successor 
name to the program information block. For detailed information 
on how you do this, see the action programming manuals. 


ACTION 
PROGRAM 


ACTION 
PROGRAM L SUCCESSOR-!ID FIELD 





Figure 3-9. Action Program Indicates Type of Termination and 
Name of Successor Program 


r When the action program finishes executing, IMS checks these 
: fields of the program information block and, on the basis of what 
they contain, arranges for further processing, if required. 
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3.12. EXAMINING A SAMPLE TRANSACTION 


To give you a better feel for how to create a transaction 
structure, let's look at a sample transaction with which you are 
already somewhat familiar. You remember that in Section 1, 
when we discussed dialog transactions, we talked about a 
transaction that displayed a customer’s account balance at the 
terminal, allowed the operator to credit payments to the account, 
and displayed the new balance. This series of events was a 
transaction structure although you didn’t realize it at the time. 
Sample transaction - Let’s look closely at that transaction - we'll call it CUSTNO - and 
CUSTNO learn the type of structures it uses. 


Scheduling the Action Program 


Checking IMS tables In 3.7 we saw how the transaction code CUSTNO (that initiated 
the transaction) was entered at the terminal and how IMS 
checked the transaction, action, and program control tables to 
determine processing requirements. 


TRANSACTION Ff fk | ACTION PROGRAM 
CODE - £24 CONTROL | CONTROL 
TABLE TABLE TABLE 





Validating an IMS Transaction Code and Determining Transaction Requirements 


When IMS found that it had sufficient resources to meet the 
Loading action program transation’s needs, it scheduled the first program (CUSTO1) and 
PuStgl loaded it and its activation record into main storage. Let's 
resume our discussion at this point. 
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MAIN STORAGE 





PROGRAM 
INFORMATION 
BLOCK 


OUTPUT 
MESSAGE 
AREA 


CONTINUITY 


DATA AREA ACTION 





a PROGRAM 
: WORK 2 pent as 
AREA 


INPUT 
MESSAGE 
AREA 


DEFINED 
RECORD 
AREA 


Action Program and Activation Record Loaded in Main Storage 


& Handling the Input Message 


CUSTO1 takes the customer number entered as input at the 
terminal and processes it. As soon as IMS schedules CUSTO1 
Loading the input and loads it and its activation record into main storage, the 


ESAge, internal message control component of IMS takes the input 

message entered at the terminal - transaction code and customer 
Using the input account number - and moves it to the input message area of 
mesoade alge program CUSTO1. The following illustration shows this. 


CUSTNO 
12345 





CONTROL DATA ACTION 


CUSTNO 12345 PROGRAM 
ey ae eas 








IMS Places Input Message in the Input Message Area 
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Processing the input 
message 


Generating the output 
message 


Using the output 
message area 








File Processing 


When CUSTO1 begins processing, it reads the input message 
area to see exactly what customer account number is requested. 
Using that number as a key, the program calls upon IMS file 
management to request OS/3 data management to get the 
appropriate customer account record. 


ACTION 


PROGRAM | FILE 


/ NT 
cusTO1 MANAGEMENT qd MANAGEME 


Action Program Accessing a Data File 


Generating the Output Message 


Once the record is retrieved and the account data is available to 
the program, CUSTO1 uses this data to generate an output 
message to be sent to the terminal. For the purpose of 
illustration, let's say the customer number is 12345 and the 
account balance is $4356.33. Using this data, the program 
creates the output message and its format in the output message 
area of the activation record. 


Naturally, since CUSTO1 knows it will generate an output 
message, it sets up an output message area to handle it. The 
message is not transmitted to the terminal at this point. That 
happens when the action program finishes processing. The 
following illustration shows how the action program generates 
output. 


CUSTOMER 
ACCOUNT 
BALANCE 
MESSAGE 


ACTION 
PROGRAM 
CUSTO1 





Action Program Generating an Output Message 























UP-9205 SPERRY UNIVAC OS/3 3-23 
IMS CONCEPTS AND FACILITIES 








TRANSACTION PROCESSING EXAMPLES 





Creating the Transaction Structure 


Setting up the transaction Before a program terminates, however, it must inform IMS what 


ehueture type of transaction structure it wants to create (Figure 3-10). 
This means that CUSTO1 has to let IMS know’ whether 
processing for this transaction is complete or not complete. 

Using the program CUSTO1 must move a termination code to the 


information block termination-indicator field of the program information block. In 


our sample transaction, there is still more processing to do. So, 
the code that CUSTO1 moves to the program information block 
is E (for external succession). 


Specifying termination External succession is needed because the transaction requires 

code more input from the terminal to continue processing. External 
succession is the only type of termination that allows for more 
terminal input (see 3.10). 


Naming successor Since a successor program does the processing that follows, 

piven CUSTO1 must identify it by moving its name to the successor-id 
field of the program information block. The successor program is 
CUSTO2. 


ACTION 
PROGRAM 


CUSTO1 





Figure 3-10. Action Program Identifies Termination Type and Successor Program 


IMS Functions at Program Termination 


Examining the program When CUSTO1 finishes processing, IMS performs several 
UNG DICS functions. First, it looks at the program information block to see 
what transaction structure was specified. It sees the E (for 
external succession) and knows to expect more input from the 
terminal. In addition, it sees the name of the successor program, 
CUSTO2, and knows that this program will continue processing 
_ this transaction. 





UP-9205 SPERRY UNIVAC OS/3 3-24 
IMS CONCEPTS AND FACILITIES 


TRANSACTION PROCESSING EXAMPLES 





Examining the output Next, IMS examines the output message area to see if there is a 

Message area message to be sent to the terminal. Since there is (the customer 
account balance), IMS internal message control directs the 
message to ICAM, the communications network. ICAM, in turn, 
sends it to the terminal. (See Figure 3-11.) 


OUTPUT INTERNAL 
MESSAGE MESSAGE 
AREA CONTROL 


ACTION 


PROGRAM 





Figure 3-11. Output Message Goes to Terminal when Action Program Terminates 


Transmitting the output The following screen shows the output message that CUSTO1 

lene generated. It displays the customer account balance requested 
and also asks for additional data. This data is the input to the 
successor program, CUSTO2. 





AR Sa os aren ccc 
a SSAOSS SE Cie weep sepia 











CUSTOMER 12345 
CURRENT ACCOUNT BALANCE = $4356.33 
ENTER PAYMENT AMOUNT $ 





LL ADE OEE ESS 


Output Message for CUSTO1 


3.13. PROCESSING THE SUCCESSOR PROGRAM 


Receiving more terminal When the terminal operator enters the payment amount, IMS 

input accepts it and schedules CUSTO2. This second input message is 
handled differently from the first. The first input message was 
the transaction code. It was validated and the appropriate action 
program scheduled. 
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@ Scheduling the successor 


program 


Now the transaction is in progress. IMS knows that the second 
input message is destined for the successor program. 
Consequently, as soon as the input is received, IMS schedules 
the successor, CUSTO2, sets up an activation record for 
CUSTO2, and places the input in CUSTO2’s input message area 
(Figure 3-12). In this case the input message is data, not a 
transaction code. 


CONTROL DATA ACTION 
PAYMENT PROGRAM 
2500.00 CUSTO2 


Figure 3-12. Accepting the Second Input Message in an IMS Transaction 





@ Processing the second Once CUSTO2 begins processing, the sequence of events is 
input message similar to what happened in CUSTO1. The program reads the 
input message area to find out how much was paid against the 

account balance. CUSTO2 computes a new account balance and 

writes it to the file containing customer account records. IMS, by 


fle Proceenne way of OS/3 data management, handles the actual writing of the 


record. 
Generating the second The program then generates an output message stating the new 
output message balance. This message is created in the output message area and 


remains there until the program terminates. 


ACTION NEW 


PROGRAM ACCOUNT 
CUSTO2 BALANCE 





CUSTO2 Generates an Output Message 
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Terminating the 
transaction 


IMS closing message 
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Before termination occurs, however, CUSTO2 must inform IMS 
what transaction structure it is creating. Since processing of this 
transaction is complete, CUSTO2 moves N (for normal 
termination) to the termination-indicator field of the program 
information block. If CUSTO2 doesn't move a value to this field, 
IMS assumes normal termination anyway. Since there is no 
successor, the program doesn’t move any name to the 
successor-id field. 


ACTION 


PROGRAM iN | NO SUCCESSOR 
CUSTO2 





CUSTO2 Identifies Termination Type as Normal 


When the program terminates, IMS sends the message in the 
output message area to the terminal (Figure 3-13) and 
deallocates all resources held by the program. 


GEOLEOL LT AOE RIN BOO 8 rs tenia 









: CUSTOMER 12345 

: OLD BALANCE $4356.33 
PAYMENT AMOUNT $2500.00 
NEW BALANCE $1856.33 


ae 





CEO ES ES 





Figure 3-13. CUSTO2 Output Message 


The receipt of the output message signifies that all IMS 
processing for this transaction is over and the operator is free to 
enter another transaction code. 
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3.14. A MORE COMPLEX IMS TRANSACTION 


In 3.11 external succession and normal termination are used to 
create transaction structures. Now, consider a more involved 
example that uses all the types of transaction structures within 
one transaction. This may sound very complex; really, it is not. 
The example we use is lengthy but the processing steps you 
have already observed are basically the same. 


Sample transaction #2 Our sample transaction uses three action programs: 





Processing the The transaction begins when the transaction code MENU is 
transaction code entered at the terminal. IMS validates this code by checking the 
transaction code table. If it is valid, IMS determines the first 
program to process the transaction and what its requirements 


are. 
Loading the action (We assume this has all been done and action program MENU 
program and its activation record are loaded in main storage.) 


Processing for Program MENU 


Processing for program MENU displays a menu screen at the terminal. It does no file 

MENU - Step 1 processing. As soon as the program receives the input message 
(the transaction code), it generates an output message in the 
Output message area of the activation record. 


Rescheduling an Then, MENU creates a transaction structure. It tells IMS there is 

action program more processing to come by specifying the termination code E 
for external succession. (This code means that more input is 
required from the terminal operator.) 


MENU also identifies the successor program. In this case, the 
successor is MENU (that is, MENU reschedules itself to continue 
the processing for this transaction). Figure 3-14 shows the 
processing for program MENU. 
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CONTRDE DATA : ACTION y OUTPUT 


[->) procram | MENU 
ee MENU SCREEN 





Figure 3-14. Processing for Action Program MENU - PASS1 





As soon as the program terminates, IMS examines the 
termination code and successor name fields and then sends the 
output message to the terminal. 












Output generated Figure 3-15 shows the menu screen, output from the program 
by MENG MENU, as it appears at the terminal. 
ABC BUILDING SUPPLIES : 
1 - ORDER ENTRY | 
: 2 - SHIPPING DATA : 
‘ 3 - WAREHOUSE INVENTORY i 
: 4 - CUSTOMER BILLING INFO : 
: ENTER YOUR CHOICE HERE : 
i AND TRANSMIT [pb } : 
EPEOGE SS SSSR SS 
Figure 3-15. Output Menu Screen Generated by Program MENU 
Entering data on the The terminal operator must choose one of the menu selections. 


output screen This choice is the input to the successor program. 








UP-9205 SPERRY UNIVAC OS/3 3-29 
IMS CONCEPTS AND FACILITIES 


TRANSACTION PROCESSING EXAMPLES 








Processing the Menu Selection 


Input received by As soon as the input reaches IMS, MENU is rescheduled and 
Seer ee Ot begins processing for the second time. 


Processing for MENU - IMS places the terminal input in the input message area of the 

Step.2 MENU activation record. This time MENU must determine what 
choice was made and to set up the transaction structure to 
process that choice. 





We assume that the operator chose menu selection. 
Indicating appropriate CUSTOMER BILLING INFO. Once the program identifies the 
successor program choice, it moves the appropriate termination code and successor 
program name to the termination-indicator and successor-id fields 
of the program information block to continue the processing. 
Figure 3-16 illustrates this process. 


ABC BUILIONG SUPPLIES 
1 - ORDER ENTRY 
2 SHIPPING DATA 
3 - WAREHOUSE INVENTORY 
4 - CUSTOMER BILLING INFO 


ENTER YOUR CHOICE HERE 
AND TRANSMIT [4] 


CONTROL AREA 


ptt S| PROGRAM pi | anes | 
MENU 
a eno aN 


ACTION 





Figure 3-16. Processing for Action Program MENU - PASS2 
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Using Immediate Internal Succession 


Using immediate In this example, MENU names BILL1 as the successor program. 
internal succession BILL1 processes customer billing information. The termination 
code is | (for immediate internal succession). 


When an action program uses immediate internal succession, it 
tells IMS that it does not need any more terminal input to 
continue processing. And, it wants processing to begin 
immediately after the current program terminates, without 
interruption. (See Figure 3-17.) 


ACTIVATION ACTION 
RECORD PROGRAM 


FOR MENU : MENU 


SAME ACTION 


ACTIVATION | PROGRAM 
RECORD : BILL1 





Figure 3-17. Activation Record with Immediate Internal Succession 


Using the same In immediate internal succession, the activation record used by 

aetvanonuecard action program MENU remains in main storage and becomes the 
activation record for the successor, BILL1. This only occurs with 
immediate internal succession. Consequently, data in the 
activation record from MENU is immediately accessible to BILL1. 


Processing for BILL1 


Processing summary for BILL1 is designed to do two things: 
program BILL1 





On the first pass through, it creates a billing screen as 
output. This screen goes to the terminal when the program 
terminates 


On the second pass through, it validates the terminal input @ 
entered on the billing screen. 
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BILL1 processing - Step 1 


Generating a billing screen 


Creating a transaction 
structure 


Transmitting the billing 


screen 


Input to the billing screen 


BILL1 processing - 
step 2 


Validating billing input 
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Here’s how that happens. . . 


When MENU terminates, IMS immediately schedules BILL1. Then, 
BILL1 does no file processing but, instead, generates an output 
message which is a billing screen. This screen requires the 
terminal operator to enter billing information about a_ specific 
customer (Figure 3-18). 


Before the screen is sent to the terminal, BILL1 (like all action 
programs) creates a transaction structure. Since BILL1 requires 
more input from the terminal, it specifies E for external 
succession. And since BILL1 validates the terminal input, it 
names itself as the successor program. 


When the program terminates, the billing screen appears at the 
terminal. (The dotted lines indicate input to be entered by the 
terminal operator.) 


ABC BUILDING SUPPLIES 
CUSTOMER BILLING INFORMATION 
CUSTOMER NUMBER: 


















PHONE: (___) __ -_ 
DATE ORDERED: __/__/ 
DATE SHIPPED: __/__/ 
ACCOUNT BALANCE: $ 


PLACE CURSOR HERE TO TRANSMIT [_} 


SES LS tess on re sonny 


a RN RG SG A ERE 


seas 


FS 








Figure 3-18. Output Billing Screen Generated by Program BILL1 


When this input reaches IMS, BILL1 is rescheduled. When the 
same program is used to do different types of processing (as 
MENU and BILL1 are), the program first checks to see what pass 
it is in. In this way it determines the processing requirements for 
this run. 


On the second pass through BILL1, the program validates the 
input coming from the terminal. For instance, it checks to see if 
the customer name and number already exist on the billing file. If 
they do, the program returns an error message to the terminal 
indicating the presence of duplicate records. 
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Creating a second 
transaction structure 


Using delayed internal 
succession 


Writing data to the 
output message area 


Naming the successor 
program 








If all the terminal input is valid, BILL1’s processing is compiete 
and it must set up the next transaction structure. This time BILL1 
specifies D for delayed internal succession as the termination 
code and BILL2 as the successor program. 


Using Delayed Internal Succession 


You use delayed internal succession when you don’t need input 
from the terminal and you want to use the output message 
created by the current program as input to the successor. Let's 
look at how BILL1 and BILL2 do this. 


If all the terminal input is valid, BILL1 takes the data and writes it 
to the output message area. Then, the program sets up its 
transaction structure. 


BILL1 specifies D for delayed internal succession as_ the 
termination code and BILL2 as the successor program. Figure 
3-19 shows the processing for BILL1. 


ABC BUILOING SUPPLIES 
CUSIONER BILLING INFORMATION 

CUSTOMER NUMBER: 

wane 

ADDRESS: 


DATE ORDERED 
DATE SHIPDED: os 
ACCOUMT BALANCE: 4 

a 


ACTION 
PROGRAM 


BILL 1 


BILLING 
DATA 


Figure 3-19. Processing for Program BILL1 
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This is the first time we've seen delayed internal succession 
used. What does it do? First, it says that BILL1 is generating an 
output message. But that message is not to be sent to the 
terminal; instead, it is to be queued by IMS as input to the 
successor program, BILL2. 


Handling output with When BILL1 finishes processing, IMS sees the termination code 

delayed internal D and moves the contents of the output message area to the 

Ser or input buffer until resources are available to schedule BILL2. Once 
BILL2 is loaded in main storage, the queued message is moved 
to the input message area of BILL2. In this way, the customer 
billing data validated by BILL1 is now available to BILL2 (See 
Figure 3-20). 


ACTION 
BILLING PROGRAM 
DATA 
BILL1 


ACTION 
BILLING | PROGRAM 
DATA 

BILL2 





Figure 3-20. Data Available to Successor BILL2 


Processing for BILL2 BILL2 begins processing by reading the input message area. 
Then, the programs calls upon IMS file management to add a 
billing record or to update the customer billing file. 


Terminating the When updating is complete, BILL2 informs IMS all processing is 
transaction over. BILL2 can specify N for normal termination or not. In either 

case, IMS normally terminates the transaction and sends a 

@ message to the terminal indicating the transaction is finished. 


Although IMS sends this message, it is better programming 
practice to end transactions with your own output message. 
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We introduced many important concepts in this section. You 
now know that there are two types of transactions: simple and 
dialog. All transactions, no matter what type, are built around 
the action, the unit of work in IMS. An action occurs each time 
there is input, processing, and output. 


Action programs are the vehicle for handling input, processing, 
and output. They do this by communicating with IMS. All this 
communication takes place in a special area that action programs 
set up, called the activation record. All data that action 
programs and IMS exchange passes through the activation 
record. 


One important exchange of data is information about the type of 
transaction structure the action program is creating. How the 
four types of transaction structures are used determines all 
transaction processing. 
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4. Generating an Online IMS 


Introducing the We've mentioned several times that IMS is a group of software 

Gono Ueton Breeese components that you can adapt to your needs. You do this using 
what is called a configuration process. The configuration 
process, however, is only one step among several needed to 
generate online IMS. 


In this section, we talk about generating your online system. The 
intent is to provide you with an overview of the steps involved. 
We talk about creating a communications network and we 
describe your files and application programs and define all the 
optional features needed to support online IMS. 


Additional information The current version of the IMS system support functions user 
guide, UP-8364, discusses the online procedure in detail. Here 
we provide an overview of the process to familiarize you with 
the steps involved. 


4.1. THE SYSTEM GENERATION STEP (SYSGEN) 


The online generation process starts at system generation 
(SYSGEN). When you first define the capabilities of your 
computer system, you enter a series of special instructions that, 
Gredting a sipeiviser once executed, create a supervisor. The supervisor is a program 
that controls the activity of other programs operating within the 
system. It regulates the flow of work to maximize productivity. 


To use IMS, you must create a supervisor that supports IMS. 
Phases of SYSGEN You do this during three phases of the system generation 

process: 

> SUPGEN 

> RESGEN (Applies only to Series 90 systems) 


> COMMCT 
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SUPGEN phase During the SUPGEN phase, you specify such things as: 


the number of communication lines 


priority levels for IMS tasks 
number of job slots required 


file locking capabilities (automatically included in 
System 80) 


in a Series 90 environment DTF, CDM, or mixed 
data management mode based on the organization 
of your data files (System 80 environment uses 
CDM mode only). 





RESGEN phase You use the RESGEN phase to generate you own system resident 
(SYSRES) disk pack. If you choose, you can use the OS/3 
release volume (OS/3REL) as your permanent SYSRES; however, 
if you decide to generate your own, you must include a RESGEN 
section in your system generation. These considerations do not 
apply to System 80 users. 





COMMCT phase You use the COMMCT phase to generate your communications 
network and an ICAM load module that supports your online 
IMS. This can be done at the same time you generate a 
supervisor or later in a separate SYSGEN. 


4.2. THE IMS LIBRARY 


As part of your IMS software, there is a collection of source, 
object, and load modules that constitute an IMS library. Many of 


Online modules these modules become part of your online IMS. They perform 
such functions as applications management and internal message 
Offline modules control. There are also offline modules that handle recovery and 


Statistical reporting operations. 
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Pre-online library In addition to the online and offline modules, the IMS library 
modules includes the following programs for pre-online processing (Figure 
4-1). 


Configuration programs: 
-  ZS#CNF for single-thread IMS. 
-  ZQ#CNF for multithread IMS. 


The configurator program is executed by an IMS jproc, 
IMSCONF. 


The NAMEREC file utility (ZP#NRU) initializes the named 
record file (NAMEREC) and generates passwords. 


The data definition processor (DT3DF) is used to create 
defined files. 


The edit table generator (ZH#EDT) controls message editing 
and validation. 


IMS 
LIBRARY MODULES 


PRE-ONLINE _ ONLINE OFFLINE 
MODULES MODULES MODULES 


DATA 
DEFINITION 
PROCESSOR 


CONFIGURATOR 
PROGRAMS 


NAMED 
RECORD 
FILE 
UTILITY 


EDIT 
TABLE 
GENERATOR 





= Figure 4-1. Pre-Online Library Module 
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4.3. PREPARING FOR ONLINE PROCESSING 


Pre-online processing Depending on the requirements of your applications, you must 
perform some or all of the following functions in preparing for 
online processing: 


Initialize the named record (NAMEREC) file, which will contain all the tables 
and records needed by. online IMS. This can be done as part of the 
configuration process or separately with the NAMEREC file utility, ZP#NRU. 





Generate passwords for use with UNIQUE, using the same NAMEREC file 


utility. 3 





Write data definitions for defined files (required, for UNIQUE and optional 
for use with your own action programs). Data definitions are processed by 
the data definition processor, DT3DF. 





Write action programs in RPG Il, COBOL, or BAL to handle specific 
applications. These programs are compiled and linked in a process 
separate from configuration. | du lush QUE oni 





Generate edit tables for use with your action programs, using the edit 
table utility, ZH#EDT. These tables simplify input message editing and 
validation 





Configure an online IMS load module, using the IMS jproc, IMSCONF. The 
configuration process also allocates and initializes the internal files needed 
by online IMS. ; 





Figure 4-2 illustrates in flowchart form IMS pre-online and online 


PIeeGes re SeqHenre processing and offline recovery functions. 


The pre-online sequence shown in Figure 4-2 is interchangeable, 
with three exceptions. You must: 


Generate the supervisor as the first step. 


Generate the ICAM load module before configuration. 


Initialize the NAMEREC file before or during configuration and 
before processing data definitions, passwords, or edit tables. 
lf the NAMEREC file is reinitialized at any time, repeat all 
pre-online processing, including configuration. 
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GENERATE COMPILE OR 


ICAM LOAD ASSEMBLE 
MODULE THAT ACTION 


SUPPORTS IMS PROGRAMS 


INITIALIZE 
NAMEREC 
FILE 


GENERATE 
EDIT TABLES 


GENERATE 
DEFINED FILES 


DEFINE 
PASSWORDS 


CONFIGURE 
ONLINE 
IMS 


INITIATE 
ONLINE IMS 
PROGRAM 


ONLINE 
PROCESSING 


May be performed by NAMEREC file utility or at configuration 
Optional for user action programs; not applicable to UNIQUE 
Required for UNIQUE; optional for user action programs 
Optional for UNIQUE not available for user action programs 


Optional 








Figure 4-2. IMS Processing 


OFFLINE 
RECOVERY 
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4.4. CREATING A COMMUNICATIONS SYSTEM 


Communications When you use IMS online, it is part of a communications system. 

environment At one end of the system is your configured IMS load module. 
At the other end are your terminals. In between is a 
communications adapter, a hardware device that takes messages 
coming from terminals and puts them in a form usable by the 
operating system and vice versa. 


Also, there is the integrated communications access method 
(ICAM). This is a software component that controls the input 
from (and output to) the terminals. 


Because of ICAM, IMS is device-independent. This means that 
you can have any arrangement of supported communications 
lines and terminals without IMS or your action programs having 
to concern themselves with the hardware they're working with. 


IMS runs as a normal 8 IMS 
user job. = S LOAD MODULE 





ICAM is the component ~ 

that controls data flow ICAM 
_ to and from the = | LOAD MODULE 
| remote terminals. 


The communications 


|, adapter aeaaatetas | COMMUNICATIONS 
with the hardware an - : ADAPTER 


___ software. 





IMS and the Communications Environment 
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Transaction control ICAM makes all communications lines and terminals compatible 

InEEHIBCE with IMS. This is accomplished through a_ special program 
designed to interact with IMS. This program is called the 
transaction control interface (TCI) portion of ICAM. This interface 
was created for use by IMS. 


4.5. DEFINING SOME TERMS 


There are a number of terms that you hear or see quite regularly 
whenever the subject is communications. We'll try to acquaint 
you with a few here. 


Defining RESIDENT and Your ICAM load module can be transient or resident. If it is 

TRANSIENT resident, it remains in main storage at all times. As a result, you 
get faster processing of transactions. If your ICAM load module 
is transient, it occupies much less main storage then the 
resident version thereby freeing up main storage for other 
programs. Transient ICAM is not available with System 80. 


Using resident and Multithread IMS requires a resident ICAM. Single-thread IMS can 
transient ICAM use either a transient or resident ICAM; but single-thread 
supporting unsolicited output requires a resident ICAM. The 

© following listing summarizes these residency requirements. 


ICAM Residency Requirements 





Single-thread (Series 90) Transient or resident 
Single-thread (System 80) Resident 
Single-thread with Resident 


unsolicited output capability 


Multithread Resident 





Defining dedicated There are two types of ICAM networks that you can define - a 
and global dedicated or a global network. 


A dedicated network supports only IMS. All lines and 
terminals defined for your network are dedicated to IMS 
for the length of the session. 


A global network supports IMS = and _ other 
@ communications programs at the same time. 
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4.6. SETTING UP THE COMMUNICATIONS ENVIRONMENT 


Defining communications 10 Create a Communications environment for use with IMS, you 
support must define the support you require. You do this with a set of 
ICAM network definition macroinstructions and system generation 
message control program parameters. This is not a complicated 


process. 
Message control The message control program parameters name the ICAM load 
parameters module, identify the disk volume where the load module will be 


stored, and define the communications adapters associated with 
your network. 


Network The ICAM network definition macroinstructions basically define 
macroinstructions three things: 


Type of ICAM support network used 


Network of lines and terminals 


input/output requirements 





CCA macroinstruction You use the CCA (communications control area) macroinstruction 
to specify whether you want a global or dedicated network. 





LINE and TERM You use LINE and TERM macroinstructions to define for ICAM 
ACES UCTS the arrangement of terminals that will be sending and receiving 
data for IMS transactions. 





DISCFILE and BUFFERS You use DISCFILE and BUFFER macroinstructions to define how 
macroinstructions input and output messages. will be handled. These 
macroinstructions set up the buffers needed to temporarily store 
the messages. The use of these macroinstructions differs 
depending on whether you're using a transient or resident ICAM. 


All the macroinstructions mentioned plus additional 
macroinstructions are discussed in detail in the IMS system 
support functions user guide, UP-8364 (current version). 
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Producing the ICAM The network definition macroinstructions are entered during the 

object module COMMCT phase of SYSGEN. Once executed, these instructions 
produce an ICAM object module. This object module is the CCA. 
During the configuration process, the CCA object module is 
linked and the resulting load module is stored in the library with 
the configurator program. 


The configurator uses the tables in the CCA load module to 
validate some of the configurator parameters. During the 
COMMCT phase of SYSGEN, the CCA object module is linked 
with the MCP parameters to create the ICAM symbiont which is 
your communications system. 
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4.7. PRE-ONLINE PROCESSING —- SETTING UP IMS 


Pre-online processing 


Requirements 


Initializing the named 
record file 


Previously in this section we talked about the IMS library 
modules you receive as part of your IMS software and the 
programs they contain. We mentioned that many of these 
programs become part of your online IMS load module as a 
result of pre-online processing. 





allocating and initializing the named record file (NAMEREC), using the IMS 
utility program ZP#NRU; 


Vv 


defining passwords, using the ZP#NRU utility program; 


creating data definitions, using the data definition processor DT3DF; 


Vv VY 


generating edit tables, using the IMS utility program ZH#EDT; and 


configuring the online IMS system. 





All pre-online processing, except configuration and setting up the 
NAMEREC file, is optional. For instance, password definition is 
not required and is used only with UNIQUE. Data definition is 
required only if you're using UNIQUE or if your action programs 
access defined files. Edit table generation is optional and is 
available to user-written action programs only. 


Initializing the named record file is required. You can do it as part 
of the configuration process or separately by running the utility 
program ZP#NRU . In either case, you must initialize the named 
record file before any other pre-online processing can take place 
because all IMS programs, including the configurator, contribute 
information to this file. 


We briefly discuss the use of the edit table generator and data 
definition processor and refer you to later sections of the manual 
where they are covered in greater detail. Here our discussion 
centers around the required parts of the IMS online generation 
process - initializing the named record file (NAMEREC) and 
configuring IMS. 
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4.8. EDIT TABLES AND DATA DEFINITIONS 


Using the edit table The edit table utility (ZH#EDT) provides a means for editing input 

utility from terminal operators and doing validation checks. Its use is 
optional. You define to the edit table generator the form in which 
you want input data to appear. The data you provide is stored 
on the named record file (NAMEREC). When input comes in from 
a terminal, IMS uses the format description stored on NAMEREC 
to verify the input based on your specifications. A further 
description and examples of how to use the edit table utility are 
included in Section 8. 


Using the data definition The data definition processor (DT3DF) is used to create defined 

processor files. You must create defined files if you intend to use UNIQUE, 
the IMS-supplied package of programs. UNIQUE accesses defined 
files only. Action programs that you write yourself can also 
access defined files. 


The data definition records produced by the data definition 
processor are written to the named record file. For a description 
of how to create defined files, see Section 10. 


@ 4.9. SETTING UP THE NAMED RECORD FILE (NAMEREC) 
As you may recall, we introduced the named record file 
Function of NAMEREC (NAMEREC) in Section 1 and further described its use in Section 
3 when we talked about action programs. By now you are well 
aware that NAMEREC is an important IMS internal file. It contains 


the records and tables needed for online IMS processing. These 
include: 


Configuration tables (transaction, action, and program control 
tables) 


Data definition records 
Edit tables 
> Password definition tables 


Initializing NAMEREC Before NAMEREC can receive this data, you must initialize it. To 
initialize NAMEREC, you can: 


run the named record file utility, ZP#NRU; or 


S specify the INIT parameter of the IMSCONF 
” job control procedure at configuration. 
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Running the named 
record utility 


4.10. DEFINING PASSWORDS 


Defining passwords 


Limited access 


PASSWORD parameter 


Other options 


> Specify the exact location on disk where the file will reside 
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When you choose the second option, IMSCONF calls in the 
ZP#NRU program to _ initialize NAMEREC as part of the 
configuration process. 


When you run the named record utility separately, you initialize 
NAMEREC and in addition you can: 


> Define passwords and change existing passwords for 
defined files 


> List the contents of the NAMEREC file 


> Process data definitons, password definitions, and edit 
tables before configuration 


In addition to uses described in 4.9, you can also use the named 
record file utility (ZP#NRU) to define passwords. The password 
definition process, an optional part of pre-online processing, 
offers data security for defined files when used with UNIQUE. 
Use of passwords is not available to user-written action 
programs. 


When you define passwords for your defined files, terminal 
Operators can access only to those files for which they know the 
password. 


To define passwords, you insert the PASSWORD function 
parameter in the job control stream to execute the named record 
file utility. This parameter names the password, associates it with 
a particular defined file or subfile, and identifies which terminals 
can access that file. Using the same parameter, you can also 
delete an existing password and substitute another in its place. 


You can also define passwords using the PASSWORD option 
available through the data definition processor at the same time 
that you're creating defined files. However, this option doesn't 
allow you to restrict access to specific terminals, nor to change 
passwords. For a discussion of how to create passwords using 
the data definition processor, consult the IMS data definition and 
UNIQUE user guide, UP-9209 (current version). 
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@ 4.11. CONFIGURING IMS 


Configuration process Configuring IMS is the most important step in generating your 
online system. It allows you to tailor IMS to your needs. One 
configuration process generates a single-thread or a multithread 
IMS. An IMS-supplied job control procedure (jproc) named 
IMSCONF generates and executes the IMS configurator program, 
produces and links the IMS load module, and stores it in the 

IMSCONF jproc library you specify. The IMSCONF jproc consists of five parts: 


CONTROL STREAM 


IMSCONF JPROC 


Links the user communi- 
cations control area (CCA CCA Linkage Step 
nto a load library file ; 


and reinitializes) IMS initialization Step 
internal files (IMS#INT) 


@ IMS#SCR 


Executes the configurator 

and generates records Configuration 
in the NAMEREC file Step 
and produces assembler 

and linker source modules 


Assembles the source 
module generated by 
the configurator 


Assembly Step Assembler | : 
ZQ#IMS |. source 
(IMSSASM) _ module 


inks IMS object modules Online Module Linkage {Linker 
and configurator output Step | source 
nto an executable ZQ2LNK (IMSSLNK) 4] modu! 
MS system and 
places system in a 
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The functions are further defined: 





CCA linkage 





Initialization 





Configurator program 





Assembly 





Online module linkage 


CCA Linkage 


The CCA linkage step links the communications control area 
object module created during SYSGEN (COMMCT) and stores 
the output in the load library containing the configurator 
program. The configurator uses data in the communications 
control area to validate the NETWORK section of your IMS 
configurator input. 


Initialization 


Initialization allocates and initializes the IMS internal files. We 
already talked about initializing the named _ record file 
separately using the named record file utility. You can also 
initialize the named record file and other internal files during 
the configuration. Later in this section we discuss initializing 
other IMS internal files. 


Configuration 


Configuration executes the configurator program, analyzes 
and processes input to the configurator (all the options you 
specify to support your IMS), generates records for the 
named record file, and creates source modules for the 
assembler and linkage editor. 


_ Assembly 


The assembly phase takes the configurator output, which 
includes information on your data files, and converts it into 
machine-readable code. 


Online Module Linkage 


Online module linkage takes the output of the configurator 
(ZO#LNK, IMS$LNK) and assembly operations and links it 
with IMS library modules into an executable IMS load module 
and stores it in a load library. 


4.12. USING THE IMSCONF JOB CONTROL PROCEDURE 


Using the IMSCONF jproc To configure IMS you call upon the IMSCONF jproc to generate 
and execute the control streams that handle the five steps 
described in 4.11. You cail upon IMSCONF as you would any job 
control procedure. The keyword parameters you _ specify 
determine which job control streams are activated. 
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© All keywords are optional and every keyword, except for the INIT 
keyword, has a default value. When you don't specify a 
keyword, IMSCONF assumes you accept the default value. Figure 
4-3 shows the IMSCONF jproc and the keywords supported. 
Note the default values terms). 
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Figure 4-3. Keywords Supported by IMSCONF jproc 
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Each of the keyword parameters that you see in Figure 4-5 and 
how you use each one is described in detail in the IMS system 
support functions user guide, UP-8364 (current version). Here is a 


brief description. 


ALTER 


CCA 


CDM 


CNFJCS 


IMSFIL 


INIT 


INPUT 


LIBS, LIBO, LIBL 


LOADM 


LST 


ZCNF 





Specifies whether any ALTER job control statements are needed. 
ALTER statements enable you to change a load module at 
execution time. 


Identifies the communications control area (CCA) object module 
created during system generation (SYSGEN). This module 
describes your communications network. It is linked to create a 
load module so the configurator can obtain CCA information 
during configuration processing. 


Designates CDM or DTF mode. Default is DTF. 


Designates specific job control streams to be run. Default runs all 
job control streams. 


Defines IMS internal files. The named record file (NAMEREC) is 
required. Depending on whether it is a single-thread or multithread 
IMS, there are other internal file requirements. 


Generates the control stream for initializing IMS internal files. You 
can initialize the named record file in a separate process, if you 
choose. 
Designates whether configurator input is on cards or in the source 
library. If in source library, defines source module name. 








Direct the configurator program where to store and obtain the 
modules created during the configuration process. You can also 
use the LIBS keyword to tell the configurator where your 
configurator input is stored. 





Assigns a name to the online IMS load module being configured. 
You use this parameter to describe your installation’s online 
system. 


Specifies various configuration listing options. Default gives you 
NAMEREC tables, configurator options, and input parameter cards 
read by the configurator. 


Identifies whether you're configuring a single-thread or multithread 
IMS and identifies the library where the configurator modules are 
stored 
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@ 4.13. INPUT TO THE CONFIGURATOR 


Types of input 


Options available 


Action program description 


During the third step of the configuration process, the 
configurator program processes input parameters. The input is 
divided into 12 sections: 





NETWORK Defines the ICAM network that supports online IMS and provides 
additional information about your IMS system. It must be the first 
section. 

GENERAL Describes general characteristics of the online IMS system, such as 


standard message size. 


OPTIONS Defines optional IMS features included in the configuration. 
TIMEOUTS Defines various timeout values. 
FILE Describes each user data file accessed by IMS. This parameter is 


entered once for each file. 


TERMINAL Further defines the terminals specified in the communications network 
definition. 
TRANSACT Supplies transaction code information to the configurator. It is coded 


once for each transaction. 





ACTION Describes the actions (units of work) used in this configuration. It is 
coded once for each action. 


PROGRAM Describes the user action programs included in this IMS configuration. It 
is coded once for each action program. 

LOCAP Defines a local application program (an IMS system) at a remote 
computer system. This input section is required with distributed data 
processing. It is coded once for each remote IMS. 


LANGUAGE Creates a UNIQUE lexicon record in the named record file. This record 
redefines UNIQUE language elements. For example, it replaces the 
UNIQUE English commands with French commands. It is coded once for 
each lexicon record 


DRCRDMGT Defines the level at which use-defined record management is used. 
Defined record management handles the processing of defined files. 





Under each input section there are numerous options from which 
you can choose. The IMS system support functions user guide, 
UP-8364 (current version) discusses these options in detail. 


In the FILE, TERMINAL, TRANSACT, ACTION, and PROGRAM 
sections, you describe the transaction codes, user-written action 
programs, files used, and terminals supported. 
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Analyzing input 


The configurator program analyzes all this input and creates 
tables that are written to the NAMEREC file. These tables are 
read into main storage at IMS start-up time. When a terminal 
operator keys in a transaction code, IMS uses the data in these 
tables to determine processing considerations for that IMS 
transaction. 


At this point the groundwork for online processing is complete. 
In Section 5 we discuss how you initiate your online IMS session. 














UP-9205 SPERRY UNIVAC OS/3 5-1 
IMS CONCEPTS AND FACILITIES 





IMS INITIATION 


5. Beginning and Ending IMS Sessions 


In Section 4 you learned about the procedures needed to prepare 
your online IMS. In this section, we talk about how you make the 
online system operational and how you shut it down when 
processing is complete. 


5.1. BEGINNING AN IMS SESSION 


IMS startup The term for bringing IMS online is start-up. There are two steps 


@ for start-up: 


Establish the communications environment 


Execute the IMS load module 





Establish the Communications Environment 


Loading ICAM To do online processing, load the communications module 
(ICAM) into main storage. (This module was created during the 
COMMCT phase of the system generation process). 


Using the console You load ICAM from the system console by keying in the name 
you specified on the mcpname parameter in the COMMCT phase 
of SYSGEN. This name identifies the communications module. 


When ICAM is successfully loaded, the message ICAM READY 
appears on the system console. 


Loading a global network If you're using a global network, you must execute the global 
user service task program (GUST) after loading ICAM. This 
program is called ML$$GI. A sample job control stream for 


executing this program is in the IMS system support functions 
& user guide, UP-8364 (current version). 
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Loading IMS 


IMS READY message 


Special considerations 








When the network is loaded, the following message appears on 
the system console: 


MC#430 GUST ACTIVE FOR CCA network-name. 


Now is the time to execute IMS. 


Execute the IMS Load Module 


You execute IMS with a standard job control stream entered at 
the card reader or workstation. You must enter the name in the 
// EXEC job control statement specified on the LOADM 
parameter of the IMSCONF jproc at IMS _ configuration. 
(Remember that the LOADM parameter uniquely identifies your 
IMS load module. This is important since you may have several 
different IMS configurations.) 


When the online IMS module is loaded, the message IMS READY 
appears at the system console and at static terminals in the IMS 
network. (Static terminals are those terminals dedicated to IMS 
for the length of the session.) 


The IMS READY message isn't displayed on dynamic terminals 
(terminals not dedicated to IMS) or if the IMSREADY=NO 
parameter was specified at IMS configuration. Once IMS _ is 
loaded, terminal operators can begin entering transaction codes. 


There are special PARAM statements you can include in your 
IMS execution job control stream. 





Whether IMS internal files and tables are to be initialized or information 
retained from a previous session (multithread IMS only) 


Rollback of data files at system startup 
Closing or extending of a disk trace file from a previous session 
b Batch transaction processing in online or offline mode 


Routing characters to identify remote systems where transactions are 
routed in distributed data processing 


Different values for distributed data processing configuration parameters 


Monitoring of the IMS session to provide additional data when there is a 
problem with the system (multithread only) 
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For a discussion of these statements and sample job control 
streams for executing IMS, consult the IMS system support 
functions user guide, UP-8364 (current version). 


5.2. ENDING THE IMS SESSION 


IMS shutdown The term for ending the IMS session is shutdown. You shut 
down IMS by entering one of the following commands at the 
master terminal: 
> ZZSHD 
> ZZHLT 


You can also enter these commands at the system console or 
master workstation if OPCOM=YES was configured. 





Orderly shutdown command shuts down IMS in an orderly fashion. No 
further transaction codes are accepted; ongoing transactions 
continue processing until timeout occurs. When no transactions 
are active, files are closed, communications lines deactivated, 


@ and IMS terminates normally. 








Emergency shutdown The 


command initiates an emergency’ shutdown 
procedure: 


No further transaction codes are accepted 


Transactions in progress are stopped 


Communications lines are deactivated 


Dd 
Files are closed 
b 


IMS terminates with a dump of main storage. 


After this type shutdown, file recovery is usually needed. 
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6. Terminal Operations and 
I/O Message Processing 


6.1. TYPES OF TERMINALS 


You know from Section 1 that IMS is a transaction processing 
system. For every message you input, you receive some type of 
response or output message. 


To input a message or receive an output message, you must 
have some way of communicating with your system. You 
communicate with your sytem through terminals. 


® Definition of terminals A terminal is any point in a system or communications network 
where data can enter or leave. You identify the type of terminals 
you have by using the TERM macroinstructions when you define 
your ICAM network. 


Use of terminals Regardless of the terminal type you choose, there are two ways 
to use terminals: 





Static terminals Static means that the terminals are attached to IMS for the entire 
IMS session. When you use static terminals, you cannot access 
any other program. Static terminals are most frequently used in 
dedicated networks where all terminals are static. However, you 
can also use static terminals in a global network. To do this, you 
define them using SESSION macroinstructions when you define 
your ICAM network. 





Dynamic terminals Dynamic terminals are only allowed in a global communications 
network. The advantage of dynamic terminals is that they're 
attached to IMS only while your're using them. 
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When you want to use IMS, you sign on the terminal to IMS by 
keying in $$SON. When you want to stop using IMS, you key in 
$$SOFF. Then you can use the terminal to access other 
programs that use the same global network. 


You incorporate the capability for dynamic session establishment 
by specifying the GAWAKE operand in the ICAM (CCA) network 
definition macroinstruction. For more information on dynamic 
terminals, see the IMS terminal users guide, UP-9208 (current 
version). 


6.2. TYPES OF INPUT AND OUTPUT MESSAGES 


Medium for input 
and output 


Types of input messages 


Definition of terminal 
commands 


Types of terminal 
commands 


Standard commands 


Regardless of the type of session you're using, whenever you 
use the terminal, you are either sending or receiving messages. 
Messages keyed in at the terminal are input messages and 
messages received at the terminal are output messages. 





Input Messages 


You can generate two types of input messges: 


Terminal commands 


Transaction-related messges 





Terminal commands begin with the letters ZZ and perform a 
variety of functions. There are two types of terminal commands: 


Standard 
> Master 
You enter standard terminal commands from any IMS terminal. 


They let you control the flow of messages to and from each 
terminal. 
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Master commands You enter master terminal commands from the master terminal 
and, in some cases, from the system console or master 
workstation. They let you control IMS and the communications 


network. 
Transaction-related You're already familiar with transaction-related messages. These 
messages include transaction codes that initiate IMS transactions and 


terminal input to successor action programs. 





There are two types of output messages you can receive at the 
terminal: 


Action program output 


IMS output 





Defining action program Action program output is composed of messages received at the 
re as terminal as a result of transaction processing. 


r Defining IMS output IMS output is messages showing the status of an IMS 
transaction or messages related to terminal commands. 
6.3. PREPARING THE MESSAGE PROCESSING ENVIRONMENT 
To process messages, IMS must be ‘‘up and running’’. This task 
is generally performed by your system administrator and includes 


the startup procedures listed in Section 5. 


When a terminal is ready | Generally, when you reach a terminal, it is sitting idle displaying 
the message: IMS READY. 





Your system administrator suppressed it with the IMSREADY=NO option at 
configuration time. 


Your terminal is dynamic (not dedicated to IMS) 
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Terminal modes 


Normal mode 


Normal mode 
processing 





Assuming your terminal is ready, you can begin sending 
messages. But, before we go any further, let’s talk about your 
terminal's behavior. 


There are two modes your terminal can be in: 


Normal mode 


Test mode 





Normal mode is the standard mode for IMS processing. 






Receives an input message 





Processes the action program and updates files if required 


Sends an output message back to the terminal 





FILE UPDATING 
ACTION PROGRAM | 


PROCESSES 
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In test mode, your IMS terminal simulates transaction processing. 
You transmit input messages and IMS processes the transactions 
as if they were actual transactions; however, no_ physical 
alteration of your data files occurs. This mode is useful in training 
new personnel and testing and debugging action programs. 






Receives an input message 
Simulates action program processing 


Sends an output message back to the terminal 


FILE UPDATING 
ACTION PROGRAM 


SIMULATES 
PROCESSING 





But your files exist as they were before the transaction occurred. 


The types of input messages you can send are terminal 
commands and transaction codes. 
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6.4. INPUT MESSAGES 


Types of terminal 
commands 


Using standard terminal 
commands 


Terminal Commands 

Terminal commands are one type of input message you can use. 
They are distinguished from other input messages because they 
begin with the letters ZZ. 


There are two types of terminal commands: 


Standard 





In this manual, we give you a brief description of each command 
and what it does. For detailed information on_ terminal 
commands, see the IMS terminal users guide, UP-9208 (current 
version). 


Standard Terminal Commands 


Standard terminal commands control message transmission and 
terminal operations and testing. You enter them from = any 
terminal including the master terminal. Some standard commands 
can also be entered from the console or master workstation (if 
console support is configured). 





CANCELS A TRANSACTION 










Cancels the currently active transaction at your terminal only. It does 
not cancel a terminal command. It is most commonly used to break 
a deadlock situation under multithread IMS. 








SUSPENDS OUTPUT TO YOUR TERMINAL 


Suspends all output to your terminal until you enter a ZZRDY 
command. It is most commonly used when the ribbon breaks or the 
paper jams on a hard copy device. 
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CHANGES THE MASTER TERMINAL 


Designates another terminal as the master terminal when the existing 
master terminal becomes disabled. The new master terminal can be: 


- your terminal 
- another IMS terminal 


- the system console (if console support is configured) 


The terminal designated as the new master terminal serves in that 
capacity only for the remainder of the session. If the old master 
terminal is revived during the session, it functions as a standard 
terminal. When a new session starts, the old master terminal is 
restored. 


RESTORES YOUR TERMINAL TO NORMAL MODE FROM TEST 
MODE 





Restores your terminal to normal mode after it operated in test 
mode. Test mode simulates normal IMS transactions to help train 
new personnel or debug and test action programs without disturbing 
online files. In test mode, no update, delete, or add functions are 
actually performed. 


RELEASES THE HOLD ON OUTPUT IMPOSED BY ZZHLD 


Returns your terminal to a state where it can receive output 
messages. This command is used when the output to your terminal 
Is suspended due to a ZZHLD command. 


RESENDS THE LAST OUTPUT MESSAGE DISPLAYED AT YOUR 
TERMINAL 


Displays the last transaction-supplied output message received at 
your terminal. You can use this command only once per message. 
When you enter a new input message, the preceding output 
message cannot be resent and IMS displays the response NO MSG 
IN QUEUE. 





PLACES YOUR TERMINAL IN TEST MODE 


Places your terminal in test mode from normal mode. Test mode 
simulates IMS transactions and enables you to test and debug action 
programs without disturbing online files. When your terminal is in 
test mode, it appears that transactions are actually taking place, but 
they are not. The ZZNRM command restores your terminal to normal 
mode. 
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Using master terminal 
commands 


Using the system 
console 


Master terminal 
commands 





Master Terminal Commands 


Master terminal commands control and monitor the entire IMS 
network. They differ from standard terminal commands because 
you can enter them only from the master terminal. You can enter 
some master terminal commands from the system console or 
master workstation when console support is configured. Master 
terminal commands entered from a standard terminal are invalid. 


When the system console is designated as the master terminal, 
you can enter all master terminal commands from the console or 
master workstation. The same is true if the master terminal is 
down and you designate the console as the master terminal 
using the ZZMCH command. 






_ ASSIGNS ALTERNATE TERMINAL 


| Assigns an alternate terminal for one that is physically or logically 
down; 1.e., messages switched to a down terminal are automatically 
- rerouted to an alternate terminal. When the down terminal becomes 
operational, rerouting is automatically discontinued. 





INITIATES AND CONTROLS ONLINE BATCH PROCESSING 


Initiates and controls online batch processing. To use this command, 
| you must configure batch processing using the BATCH parameter in 
the NETWORK section of the configurator and include the PARAM 
- BATCH statement at IMS startup. 





CLOSES A DATA FILE 


; Closes a data file so non-IMS users can access it. You are not 
_ informed that the file is closed unless you try to access it. This 
command cannot close a defined file. To reopen a closed file, use 
the ZZOPN command. 


MARKS DOWN A MALFUNCTIONING TERMINAL 





_ Logically disables a terminal. It is most commonly used when a 
_ terminal in the network is malfunctioning. This improves response 
time for other terminals in the network. 





IMMEDIATELY TERMINATES AN IMS SESSION 


Terminates the IMS session. Use this only in emergency situations 
because all transactions in progress are aborted and not rolled back. 
This necessitates offline recovery or a warm restart for the next IMS 
session. 
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OPENS A DATA FILE 

Reopens a data file that was closed by the ZZCLS command. 
REPLACES AN ACTION PROGRAM IN THE LOAD FILE 
Allows you to: 


- debug action programs or correct programs and replace the old 
version with a new one 


7 add an action program that was missing at startup to the load 
library 





SHUTS DOWN THE IMS SESSION IN AN ORDERLY MANNER 


Shuts down the IMS session: 


- after all transactions in progress are completed, or 


- when a shutdown timeout period expires 





DISPLAYS TERMINAL STATUS 


_ Displays the following information about a specific terminal in the 
network: 


= current status 


= number of messages, transactions and commands since the 
start of the IMS session 


- name of an alternate terminal (if there is one) 


TESTS A TERMINAL’S STATUS 





Tests a specific terminal to see if it can receive output. To use this 


- command, you must specify unsolicited output in your configuration. 












MARKS UP A PREVIOUSLY DOWNED TERMINAL 





- Restores a terminal that was previously marked as inoperative by a 


- ZZDWN command 
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Defining transaction 
codes 


Types of transaction 
codes 


Defining user transaction 
codes 


Types of user transaction 
codes 


Using 1-8 character 
codes 


Transaction Codes 


Transaction codes are messages that identify a transaction to 
IMS. When you enter a transaction code, IMS finds the action 
program assigned to that transaction code and processes the 
transaction. Once you start a transaction, you can’t initiate 
another transaction or issue certain terminal commands until the 
transaction is complete. 


There are two types of transaction codes: 


Transaction codes for your action programs 


Transaction codes for IMS-supplied action programs 





Transaction Codes for Your Action Programs 


When you write your own action programs, IMS must know the 
names of all your transaction codes and the action programs 
related to them. You tell IMS this in the TRANSACT section of 
your configuration. You can designate a 1- to 8-character code 
for multithread, or a 1- to 5-character code for single thread, or a 
function key as your transaction code. You key in this transaction 
code or press the function key to begin a transaction. 


When you write your own action programs, you must designate 


transaction codes to access them. There are two types of 
transaction codes: 


Alphanumeric messages 


1 to 5 characters in single-thread IMS 
1 to 8 characters in multithread IMS 


Function keys 





Whether you use alphanumeric messages or function keys as 
your transaction codes, you must identify them to IMS in the 
TRANSACT section of your configuration. When IMS receives the 
transaction code as input, it accesses the appropriate action 
program. Your action program must be prepared to receive the 
transaction code as the first field of its input message. 
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Using function keys 


Processing function 
key input 


Function Keys 


Function keys are fast, efficient, and provide less margin for error 
than do the alphanumeric messages. Depending on the type of 
terminal you have, you can use the function keys as follows: 





UNISCOPE Display Terminal F1-F4 
UTS-400 Terminal F1-F22 
IBM 3270 Terminal F1 - F33 





When your terminal is not processing a transaction and is sitting 
idle, any function key entry is interpreted as a transaction code. 
When IMS receives your function key as input, it accesses the 


appropriate action program. 





Using a Function Key as a Transaction Code 


ACTION 
PROGRAM 
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In addition to using a function key as a transaction code, you can 
also use it aS a response to an output message. You use a 
function key in this capacity with external succession. You define 
the function key in your action program as the input message for 
the successor program. When the action program sends the 
output message requiring a response, the operator presses the 
defined function key and transaction processing continues. 


ACTION 
PROGRAM 
1 
PROCESSES 


ACTION 
PROGRAM 
2 
PROCESSES 





Using a Function Key with External Succession 
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Transaction Codes for IMS-Supplied Action Programs 


IMS supplies you with a number of action programs that perform 
specific functions. These programs are accessed by special 
transaction codes that IMS recognizes. There are 7 IMS 
transaction codes, 4 can be entered from any terminal and 2 can 
be entered from the master terminal only. The transaction code 
SWTCH is used for both regular and master terminals. 


Enter the following five transaction codes at any terminal: 


| DISPLAYS DATA IN CONFIGURATOR TABLES 


Displays the contents of specified fields in your ACTION and 
PROGRAM configurator tables. 


DISPLAYS THE LAST EFFECTIVE OUTPUT MESSAGE 


Displays the last effective output message sent to your terminal from 
| an action program or UNIQUE. Use this transaction code when: 


- you cancel a transaction or one terminates abnormally and you 
need to determine where to resume updating 


- you want to receive the last effective output message from a 
specified terminal 


- you want to receive the last effective output message before a 
cold or warm restart 


DOWNLINE LOAD A UTS PROGRAM 


Loads a user-written UTS program from the IMS load library 
downline to a UTS 40 or UTS 400 terminal. To use this transaction 
code, you must specify DLOAD=YES in the OPTIONS section of 
your configuration. 


INITIATES AN OS/3 JOB 


Runs an OS/3 job from an IMS terminal. Initiates a system command 
that reads a job control stream and schedules the job for execution. 


SENDS A MESSAGE TO ANOTHER TERMINAL OR TERMINALS 


Sends a message to other terminals, including the system console. 
Used when you have an important message to send to other 
terminals. To use this command, you must specify unsolicited 
output, using the UNSOL parameter in the OPTIONS section of your 
configuration. 
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Enter the following transaction codes only at the master terminal: 


SENDS A MESSAGE TO ALL TERMINALS 

Sends a message to all terminals in the IMS network. 

CHANGES CONFIGURATION TABLES 

When you do your configuration, you may make several entries in 
the ACTION and PROGRAM sections of the configurator. At some 
time, you may want to change these specifications. The CHTBL 


transaction code lets you make temporary changes to the internal 
tables generated by your entries in these sections. 


GENERATES STATISTICAL DATA 


Generates statistics about your files, programs, transactions, and 
terminals. You can send these statistics to: 


- the master terminal 


- the master terminal and an auxiliary device (terminal, printer, 
cassette, or diskette) 


- a special data file (STATFIL). You print the contents of 
STATFIL with the statistical file print program. 
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6.5. OUTPUT MESSAGES 


Action program output 


Handling a single 
output message 


There are two types of output messages: 


Action program output 


IMS output 





ACTION PROGRAM OUTPUT 


The first type of output is generated by action programs as a 


result of action processing. This output can be: 


a single message; 
multiple messages; 
a switched message; or 


a special feature message. 


Single Message Output 


With single message output, the action program produces one 
output message only. This message is created in the output 
message area of the activation record and is sent to the terminal 
when the program finishes processsing. 


ACTION 1 ACTIVATION 
PROGRAM RECORD 


TERMINATES WITH 


OUTPUT MESSAGE 
IN OMA {OUTPUT 
MESSAGE AREA} 


Single Message Output 
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Generating multiple 
output messages 


Handling multiple 
output messages 


Using an ICAM queue 








Multiple Message Output 


With multiple output messages, the action program produces 
more than one output message using SEND functions. An action 
program does this when the output is greater than screen 
capacity. (If your message is too long for one screen, the excess 
data wraps around and deletes the beginning data output.) The 
program is designed to output only the amount of data that will 
fit on one screen. This will vary depending on the screen size. 


The first output message created stays in the output message 
area until the program generates the second message. Since the 
output message area holds only one output message at a time, 
something must be done with the first message before the 
second message is generated. Consequently, IMS takes the first 
message and moves it to an ICAM queue where it remains until 
the program finishes processing. 


ACTIVATION 
RECORD 


ICAM 


f First Output I 


message queues 


Multiple Message Output 


As soon as IMS removes the first message from the output 
message area, it is ready to hold another output message. 


SECOND ACTIVATION 
QUTPUT RECORD 
MESSAGE 


Program terminates and 
messages are sent to 
terminal one at a ume 
in the order they were 


created 


Holding Output Message 
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Repeating the process 


Sending multiple output 
to the terminal 


Message waiting 
indicator 


Restrictions with 
multiple output 


If the action program generates numerous output messages, the 
process repeats over and over until all processing is complete. 


IMS moves each successive output message to an ICAM queue 
to free up the output message area. 


When the program finishes processing, IMS notifies ICAM; ICAM 
then begins to send the output to the terminal. The messages 
are sent one at a time in the order they are created. 


ICAM sends the first output message to the terminal and then 
notifies the terminal operator of each successive message. This 
notification is an indicator light or a message. 


If you have a display terminal, this indicator is usually the 
MESSAGE WAITING light. 


When you have a hard copy terminal, it’s the message 
/CMW or another 4-character message you define in your 
communications network definition. 


For a list of message waiting indicators for specific device types, 
see the IMS terminal users guide, UP-9208 (current version). 


When you have multiple output waiting, ICAM displays the 
indicator before each message. You must accept all queued 
multiple output messages before you can start another IMS 
transaction as shown by the following illustration. 


OUTPUT MESSAGE 1 


_ Message waiting 
key acknowledge 
message and 
erminal is free 
O receive second 

output message 





Accepting Multiple Input 
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Introducing terms 


CALL RETURN function 


CALL SEND function 


Defining switched 
messages 


How to send 
switched output 


Queueing switched 
output 


Message waiting 
indicator 





Handling Output Messages 


Before we talk about the other two types of output (switched 
and special feature output), there are two terms we_ should 
introduce. You will see these terms often in the IMS action 
programming manuals. The terms are concerned with how IMS 
handles output messages. 


RETURN 


Both a single output message or the last output message 
generated by an action program is handled as a RETURN 
function in IMS. 


SEND 


Multiple output (but never the last output message) 
generated by an action program is passed as a SEND 
function to IMS. Switched output, as well as several special 
types of IMS output, are sent using the SEND function. 
Whenever a program uses this function, you must specify 
the UNSOL parameter in your IMS configuration. 





Switched messages are messages sent to your terminal as a 
result of an input message from another terminal. The input 
terminal can send a switched message one of two ways: 


a> From an action program using the SEND function 
2> From a terminal using the IMS transaction code SWTCH 


Normally when you receive a switched output message, it's at 
the end of a transaction because these messages are queued at 
the terminal until the transaction in progress is completed. Then, 
you are notified by the applicable message waiting indicator. 





(You could also receive the message waiting indicator at the end 
of each action if you configured UNSOL=ACTION). 
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Receiving switched 
messages 


Reference material 





When you receive this indicator, you can either: 
> ignore it and transmit another input message; or 
accept it by pressing the MESSAGE WAITING key on your 


display terminal or the CTRL/G and CTRL/C keys on 
hard-copy devices. 


For message waiting responses of specific devices, see the IMS 
terminal users guide, UP-9208 (current version). 





Since there are a large variety of special output messages, they 
are discussed in Section 8 of this manual. 
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Types of IMS messages 


IMS READY message 


Automatic status 
messages 


Canceling a transaction 


IMS error message 





You can also receive IMS messages at your terminal. These 
include: 


> IMS READY message 

> Automatic status messages 

> IMS error messages 

Responses to terminal commands 


The IMS READY message signals to the terminal operator that 
IMS is prepared to accept an input message. 


Automatic status messages notify a terminal operator of the 
status of the last input message. Multithread IMS generates these 
messages when there is a delay in processing an input message. 
The following list identifies the three automatic status messages 
and their meanings. 












INPUT IN QUEUE IMS received the input message but did not pass it to the 


action program. 


INPUT IN PROCESS The action program is now processing the input. 


ROLLBACK IN PROCESS The action program terminated abnormally and your updated 


files are being restored to the last rollback point. 


Any time after you receive the first status message, you can 
cancel the transaction by keying in the ZZCNC_ terminal 
command. Any other input you enter before receiving an output 
message Is ignored. 


IMS error messages result when an action program terminates 
abnormally. For a complete list of error messages, consult the 
OS/3 system error messages programmer/operator reference, 
UP-8076 (current version). 


When you enter a terminal command, IMS sends a response 
message letting you know that the command was processed. For 
instance, when you enter the ZZTMD command, you receive the 
message: 


TERMINAL IN TEST MODE 
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6.6. INPUT AND OUTPUT AT THE SYSTEM CONSOLE 


You can also enter and receive messages at the system console 
and the master workstation (if there is one) when: 


Configuration > You configure OPCOM=YES in the OPTIONS section, or 
requirements 
You configure the console as the master terminal by not 
including MASTER=YES in any TERMINAL section 


When there is a master workstation, you can enter messages 
from the console and workstation, but only one message from 
either source can be processed at a time. Response output 
messages go to the device at which the message was entered. 


The console or master workstation functions as the master 
terminal when you omit MASTER=YES or when the master 
terminal is down and you use the ZZMCH command to designate 
the console as the new master terminal. You must configure 
OPCOM=YES to designate the console as the master terminal 
using ZZMCH. 


6.7. USING MASTER AND STANDARD TERMINAL COMMANDS 
@ FROM THE CONSOLE 


Terminal commands When the console is the master terminal, you can use all master 

available terminal commands. When you _ configure console support 
(OPCOM=YES) but the console is not the master terminal, you 
can use the ZZSHD and ZZHLT to shut down the IMS session, 
but other master terminal commands cannot be entered. 


You can enter four standard terminal commands from the 
console: 


> ZZCNC 
> ZZTMD 
> Z2ZMCH 
> ZZNRM. 


Three standard terminal commands cannot be entered: 


> ZZHLD 


eZ 
& ZZRDY 
> 


ZZRSD. 
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6.8. TRANSACTION PROCESSING FROM THE CONSOLE 


IMS transaction codes 
supported 


User transaction 
codes supported 


When you configure console support, you can enter transactions 
from the console (or master workstation if there is one) just as 
you do from any terminal. However, there are limitations on the 
kinds of transactions you can use because of these restrictions 
on message size: 


> The maximum length of an input message is 60 characters. 


The maximum length of an output message is 120 
characters. 


You can use the IMS transaction codes DLMSG and SWTCH; 
however, UNIQUE is not effective at the console because the 
output screens are too large. The same is true of the ZSTAT 
transaction. You can use ZSTAT, but you must direct output to a 
data file, STATFIL, because the display screens are too large. 


A complete discussion of console transaction processing is 
discussed in the IMS terminal users guide, UP-9208 (current 
version). 














e 
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IMS internal files 


User data files 





7. File Activity with IMS 


In this section, we talk about both user files and IMS files. As 
you know from the discussion of preparing an online IMS system 
in Section 4, there are certain IMS files that handle online and 
offline IMS processing. To establish processing capabilities, you 
must initialize these files during IMS configuration. Although we 
talked about initialization, we didn’t talk about the files 
themselves and what they do. We do this in this section. 


You are also aware from Section 3 that action programs perform 
file processing. This processing involves user data files or defined 
files — retrieving, updating, inserting, and deleting records. How 
this happens is also a subject of this section. Let’s begin by 
talking about file processing in the action program environment. 


7.1. ACTION PROGRAM FILE PROCESSING 


Action program file 
processing 


File management 


Files supported 


The primary activity of action programs is processing input 
messages and producing output messages. More often than not, 
this involves some form of file processing. The terminal operator 
wants to look at a record, add a record, change a record, or 
perhaps delete it altogether. Each of these activities is a form of 
file processing. 


Action programs themselves don’t handle the actual reading and 
writing of records. IMS handles all |/O. Consequently, each time 
an action program wants to access a file, it begins by issuing a 
call to IMS file management. File management, in turn, calls on 
OS/3 data management which retrieves the desired record and 
passes it back to IMS. Figure 7-1 illustrates this process. 


IMS file management makes records available to action programs 
for processing. File management supports sequential, relative, 
and indexed files. In addition, it supports defined files in an 
indexed file organization via defined record management. 
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COBOL and basic 
assembly language 
function calls 


RPG I! function calls 


Summary of files and 
function calls 


ACTION LOGICAL LOGICAL PHYSICAL 
PROGRAM \\ RECORDS i MANAGEMENT, RECORDS RECORDS 


MANAGEMENT 
L 








Figure 7-1. How IMS Accesses Your Data Files 





D> COBOL and 
COBOL and basic assembly language (BAL) action programs 
communicate directly with file management in making file 
requests. They do this through I/O function calls: GET, 
GETUP, PUT, DELETE, INSERT, SETL, SETK, and ESETL. 





These calls are processed by SAM, DAM, ISAM, and 
MIRAM data management access methods. (To access IRAM 
files, you must define them as MIRAM files at configuration.) 
System 80 supports MIRAM files only. 





RPG Il programs do not issue function calls. The RPG J 
compiler converts normal RPG Il programming file requests 
into function calls to IMS file management. 


No matter what the programming language, it is the function call 
(be it from the action program directly or through the compiler) 
that alerts IMS file management to handle a file request. From 
that point on, file management interfaces with OS/3 data 
management to do the actual reading and writing of records. 


Table 7-1 summarizes the file types that IMS supports and the 
function calls that action programs perform on these files. 
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Table 7-1. Summary of File Types Supported by IMS File Management 











Sequential Sequential 


SAM/dedicated MIRAM Retrieve, Append 
{tape and disk) (write unblocked output) 
Relative Random DAM/MIRAM Retrieve, Update, Insert, Delete 
(nonindexed) 
Sequential MIRAM Retrieve 
Indexed Random ISAM/MIRAM Retrieve, Update, Insert, Delete 
Sequential ISAM/MIRAM Retrieve 
Defined File Random ISAM/DAM/MIRAM Retrieve, Update, Insert, Delete 
Sequential ISAM/DAM/MIRAM Retrieve 


File types Table 7-1 shows that there are four file organization types: (1) 
sequential, (2) relative, (3) indexed, and (4) defined files. Each of 

File access these file types can access records randomly or sequentially 
(except for sequential files which can only access records 
sequentially). 


Random access means that there is no prescribed order for 
accessing records. They can be called upon in any order the 
Riaiies a a4 program desires. 
sequential access 
Sequential access means that records are retrieved one after 


another, in the order they exist on the file. 


The discussion of function calls begins with requests made to 
indexed and relative files. 


7.2. INDEXED AND RELATIVE FILES 


A key specification characterizes most function calls issued to 
Indexed files indexed files. Each record in the file is identified by a specific 
key. 


A relative record number characterizes most function calls to 
Relative files relative files. Each record in the file is assigned a number relative 
to its position in the file (first, second, third, and so forth). 


Since the result of function calls to relative and indexed files is 
the same, we discuss function calls only. However, the actual 
coding of the function calls for indexed and relative files differs. 
For a description and explanation of that coding, consult IMS 
action programming in COBOL and basic assembly language user 
guide, UP-9207 (current version). 
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Random Function Calls 


Random file access means that you can access records in any 
order. For indexed files, you define the record by key; and for 
relative files, by relative record number. 


Defining random The random function calls are: GET, GETUP, PUT, INSERT, and 
function calls DELETE. Table 7-2 summarizes what these calls do: 


Table 7-2. Random Function Calls for Relative and Indexed Files 





GET Only retrieves the record. 


GETUP Retrieves the record for updating and locks the record from access by 
other transactions. 


PUT Used with the GETUP function to write an updated record back to the 
file. 

INSERT Places a new record into the file or overwrites a previously deleted 
record. 

DELETE Used with the GETUP function to delete a record that was retrieved for 
updating. 





Sequential Function Calls 


Sequential file access means that you access records in the order 
they exist in the file, one after another. 


Defining sequential The sequential function calls are SETK, SETL, GET, and ESETL 
function calls for COBOL and BAL. Table 7—3 summarizes these function calls 
and what they do: 


Table 7—3. Sequential Function Calls for Relative and Indexed Files 





SETK Changes the key of reference for multikeyed MIRAM files 


SETL Sets an indexed or relative file into sequential mode and logically 
positions the file according to your specifications 


GET Retrieves the next logical record in sequential order 


ESETL Changes an indexed or relative file from sequential back to random 
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For special considerations regarding the use of function calls with 
indexed and relative files, see IMS action programming in RPG Il 
user guide, UP-9206 (current version) and IMS _ action 
programming in COBOL and basic assembly language user guide, 
UP-9207 (current version). 


7.3. SEQUENTIAL FILES 


You can only access sequential files sequentially; that is, one 
record after another as they exist on the sequential file. There are 
two function calls to sequential files: GET and PUT. 


Processing sequential There is one point to remember about sequential files in an 

files action programming environment; you can not use the same 
sequential file for both input and output. It must be either one or 
the other. Files configured for input can only be accessed by the 
sequential GET function. Files for output can only be accessed by 
the sequential PUT function. 


In RPG Il, you can access sequential files for output only, not 


input. 
Function calls for The sequential GET function retrieves the next logical record in 
sequential files sequential order; and the sequential PUT function writes logical 


records to sequential files on tape or disk. 


7.4. DEFINED FILES 


Accessing defined files Defined record management is a subcomponent of IMS file 
management. Defined record management handles requests made 
by action programs to access defined files. 


ACTION DEFINED PHYSICAL 
PROGRAM \_ RECORDS RECORDS 
NET i 





Accessing Defined Files 
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Function calls supported 


Restrictions 
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Action programs can access defined files using random access 
functions GET, GETUP, PUT, INSERT, and DELETE or sequential 
access functions SETL (SETLL), GET, and ESETL (ESETLL). These 
functions perform the activities described in Tables 7-2 and 7-3. 


A transaction can access only one defined file during a given 
action. However, it can also access ISAM, SAM, DAM, or 
MIRAM files if they're not referenced by the defined file. For 
detailed information on accessing defined files, consult the IMS 
data definition and UNIQUE user guide, UP-9209 (current version) 
and Section 10 of this manual. 


7.5. STATUS OF FILE REQUESTS 


Results of function calls 


Defining a program 
information block 


Status code and detailed 
status code 


After each file request made to IMS file management, IMS 
returns a value indicating the result of that request. This value is 
placed in the program information block. 


ACTION FILE DATA 
PROGRAM MANAGEMENT MANAGEMENT 


PROGRAM 
INFORMATION 
BLOCK 





Returning a Status on Action Program Function Calls 


COBOL and BAL programs must always define a program 
information block. The RPG Il compiler automatically provides a 
program information block if the RPG II program doesn’t define 
one. 


The first four positions of the program information block contain 
the status code and detailed status code fields. The status code 
(positions 1 and 2) defines whether or not the function call was 
successfully carried out; and if not, why not. The detailed status 
code (positions 3 and 4) contains specific information about why 
the function call was unsuccessful. 
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ACTION 


PROGRAM 





Status and Detailed Status Code Fields in the Program Information Block 


Successful and If both the status and detailed status code fields contain zeroes, 

unsuccessful the function call was successful. If one or the other is not zero, 

function calls some error occurred. The current versions of IMS action 
programming in RPG Il, UP-9206, and IMS action programming in 
COBOL and BAL, UP-9207, list error codes for all file function 
calls. 


It is good programming practice to design action programs to 
Y ) check these fields after each function call request to determine 
what values they contain. 


7.6. FILE PROCESSING CONSIDERATIONS 


Defining user data files You define all files used by action programs in the FILE section 
of the IMS configuration. You code a FILE section for each of the 
data files your action programs access. This FILE section 
provides to the configurator program detailed information about 
each file such as the file name, file type, type of record locks to 
be imposed, whether you want offline recovery for the file, data 
management interfaces for the file, etc. Single-thread users must 
specify RECLOCK=YES to obtain record locking. 


The file definitions are stored on the named record file in the file 

control table. At IMS start-up, all files defined by the configurator 
Opening and closing are opened. They remain open until closed by IMS shutdown 
wees procedures. 


Files can also be closed and reopened from the master terminal 
via the master terminal commands, ZZCLS and ZZOPN. No 
capability exists to open and close files from an action program. 


& Additional file parameters \f you intend to use UNIQUE for file updating or if your action 
programs update files, you must also configure FUPDATE=YES 
in the OPTIONS section of the configuration. 
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7.7. LOCKING RECORDS 


Using record locks 


Lock options 


Defining 
lock-for-transaction 


Additional locking 
capabilities 


When your IMS transaction updates 
records in a file, you want to be sure 
that no other transaction is updating 
those records at the same time. For this 
reason, IMS_ provides a_ protection 
feature calle 





You can either lock-for-update or lock-for-transaction. You 
specify one of these using the LOCK parameter in the FILE 
section of the IMS configuration. If you don't specify the LOCK 
parameter, IMS automatically provides lock-for-transaction. 


Lock-for-Transaction 


When you select lock-for-transaction (LOCK=TR) or omit this 
parameter: 


> IMS locks records being updated until the end of the action. 


> Updates are audited. This means that an image of the record 
before it is updated (before-image) is written to the audit file. 
If the transaction terminates abnormally, the original image of 
the record is restored. This process is called rollback. 


Lock-for-Update 
When you select lock-for-update (LOCK = UP): 
D IMS locks records only for the duration of the update. 


p> Updates are not audited and not rolled back if the 
transaction terminates abnormally. 


in addition to the lock-for-update and _ lock-for-transaction 
specifications, there are also special lock rollback indicators and 
an UNLOCK function call that you can use in your action program 
to control even further the use of record locks. For more 
information on use of the lock rollback indicators and UNLOCK, 
see IMS action programming in COBOL and basic assembly 
language user guide, UP-9207 (current version) and IMS action 
programming in RPG II user guide, UP-9206 (current version). 
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IMS INTERNAL FILES 


By now, you are well aware that there are several IMS internal 
files that function either during IMS pre-online processing, online 
processing, or offline processing. The IMS internal files are: 





The named record file (NAMREC) is a required IMS file. It 
contains all the control tables generated by the configurator and 
records from pre-online processing. A NAMEREC file can contain 
records from as many as 255 different IMS configurations. 
However, if you have more than one IMS online at the same 
time, they cannot access the same NAMEREC file. 





The audit file (AUDFILE) is a required file for multithread IMS. It 
handles online recovery. Before IMS updates any record, it places 
an exact image of that record on the audit file. If the transaction 
terminates abnormally or invalid data is entered at the terminal, 
IMS reproduces the original record using the audit file. The audit 
file also contains IMS control information recorded when a 
transaction terminates. 





The continuity data file (CONDATA) is a required file for 
multithread IMS when you use UNIQUE. It also is used when your 
action programs pass data using the continuity data area, or if 
you use the terminal output message file TOMFILE. 





The trace file (TRCFILE) is required for both a single-thread and 
multithread IMS if you want offline recovery capabilities. With 
offline recovery you can recover your data files at a time when 
IMS is not online.The trace file, unlike other IMS internal files, can 
be on disk, diskette, or magnetic tape. 





The audit and continuity data file (AUDCONF) is the single-thread 
IMS counterpart of the AUDFILE and CONDATA files for 
multithread IMS. It is always required. 
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The terminal output message file (TOMFILE) is part of the 
single-thread AUDCOMF file or of the multithread CONDATA file. 
During online processing, IMS writes to the TOMFILE the output 
message generated for each terminal at rollback points and at 
transaction termination, retaining only one message per terminal 
on the file. The terminal operator can redisplay the most recent 
output message which resulted from file updating by entering the - 
transaction code DLMSG. These output messages are also 
recorded on the trace file for offline recovery if you specify 
TOMTRCE=YES in the OPTIONS section of the configuration. 
You must also specify TOMFILE=YES if a warm restart will be 
used. 





The statistical data file (GSTATFIL) is optional for both single and 
multithread. It contains statistical data recorded during online 
processing. 





The fast loader file (LDPFILE) is required when you include 
FASTLOAD=YES in the OPTIONS section of configurator input. 
Action programs are copied into this file from the action program 
load library (LOAD) the first time they are called from a 
transaction and then are loaded from the LDPFILE. 


7.9. ALLOCATING AND INITIALIZING INTERNAL FILES 


Assigning and initializing 
internal files 


You can allocate and _ initialize most IMS _ internal files while 
executing the IMSCONF job control stream. You use the IMSFIL 
and INIT keyword parameters. We discuss these parameters in 
Section 4. Only the NAMEREC file can be allocated and initialized 
in a separate process, using the named record file utility. You 
must also assign the internal files in the job control stream at 
IMS start-up. For a complete discussion of initialization and 
start-up procedures, consult the IMS system support functions 
user guide, UP-8364 (current version). 
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7.10. RECOVERY 


Types of recovery Whenever you're updating files, you want the security of 
knowing that if something goes wrong, your files can be 
restored. IMS provides a complete file recovery system that 
Operates in both online and offline environments to ensure the 
protection and security of your data files. 





Requirements for Online recovery is automatic when you specify FUPDATE=YES in 

online recovery the OPTIONS section of the IMS configuration. You must, of 
course, have also initialized an audit file (AUDCONF for 
single-thread IMS and AUDFILE for multithread IMS) during IMS 
configuration and assigned it in the job control stream at IMS 
start-up. IMS stores a before-image of each record for updating 
on the audit file. In this way, records can be restored to their 
orginal form. 


© 
PROGRAM 
DATA 
MANAGEMENT 
RECORD IS 


UPDATED 





Writing Records to the Audit File 


Occurrencee-of Every time a transaction terminates abnormally, if you specified 

online recovery TOMFILE=YES in the OPTIONS section, IMS automatically rolls 
back your files to the state in which they existed at the start of 
the transaction or to the last rollback point if you so specified in 
your transaction. 


IMS also rolls back your files at system start-up if you specify a 
warm restart; in this case, all transactions that were active at the 
@ time IMS terminated are rolled back. 


In both of these cases, IMS uses the before-image of records 
stored on the audit file to restore files to their original state. 
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Requirements for 
offline recovery 


Summary of online 
and offline recovery 





Offline recovery is performed by an IMS utility program, ZC#TRC, 
after all online processing has terminated. To have offline 
recovery capabilities, you must specify the RECOVERY parameter 
in the OPTIONS section of configurator input. In addition, you 
must initialize a trace file and assign it at start-up. IMS records 
before-images, after-images, or both (depending on what you 
specify in the RECOVERY parameter) on the trace file so that you 
have complete recovery capabilities. 


The offline recovery program restores files that are physically 
damaged or that contain inaccurate data. 


A second offline utility, ZC#TCP, copies and closes a tape trace 
file left open by system failure. When a tape file is left open, you 
must use ZC#TCP to copy it before you can use it for recovery. 


Table 7-4 summarizes the online and offline recovery functions, 
the internal files used for each, and the configuration parameters 
required. 


Table 7-4. Recovery Options 














Online Rollback: Audit file (AUDCONF) | FUPDATE, TOMFILE 
® Online transaction rollback|for single-thread. (TOMFILE required for 
m Warm restart AUDFILE for warm restart only) 
multithread. 
Display last effective Terminal output FUPDATE, TOMFILE 
output message message file 
(DLMSG transaction) (TOMFILE partition of 
AUDCONF or 
CONDATA file) 
Offline Utility programs: Trace file (TRCFILE) FUPDATE, RECOVERY 
= Offline recovery utility 
(ZC#TRC) 
m Tape copy routine 
(ZC#TCP) 
Recover TOMFILE in TRCFILE, TOMFILE FUPDATE, RECOVERY 
addition to data files TOMFILE, TOMTRCE 


“All configuration parameters listed are specifie section. 


Since online recovery happens automatically once you have 
configured FUPDATE=YES, there is really no additional concern 
for the user. Consequently, we devote the remainder of our 
discussion to the offline recovery procedures. 
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@ 7.11. TYPES OF OFFLINE RECOVERY 


Types of offline recovery The ZC#TRC offline recovery program provides three forms of 
offline file recovery: 


Forward recovery 


Backward recovery 


Quick recovery 





Using a backup file You use forward recovery when a portion of your data files is 
destroyed. To do this, you must first have a backup copy of the 
original files. To find out how you create backup files, see the 
OS/3 system service programs (SSP) user guide, UP-8062 
(current version). 


The ZC#TRC utility updates your backup file using the 
after-images recorded in the trace file. If you specify that the 
@ terminal output message file, TOMFILE, is to be recovered in 
addition to your data files, ZC#TRC copies to the TOMFILE the 
last Output message recorded in the trace file for each terminal 
up to the recovery point. 


Using after-images 





You use backward recovery when your data files are still 
accessible but may contain invalid data. ZC#TRC uses 


Using before-images before-images recorded on the trace file to restore your data files 
to their original state or to the state they were in at a date and 
Restoring the TOMFILE time you specify. You can also recover your TOMFILE during 


backward recovery. 





You use quick recovery in the case of system failure or 
emergency IMS termination. Quick recovery rolls back all 
transactions active at the time of termination. ZC#TRC uses 
before-images on the trace file to roll back your transactions. 
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7.12. RUNNING THE OFFLINE RECOVERY PROGRAM 


Recovering active 
transactions 


Linking the recovery 
module 


Executing the offline 
recovery program 


Using the tape 
copy routine 


Before you can use the offline recovery program, ZC#TRC, you 
must link the recovery object module, ZE#OLREC, with the object 
module containing your configuration control tables and _ file 
definitions and with the appropriate data management modules. 
The IMS system support functions user guide, UP-8364 (current 
version) provides sample job control streams for linking 
ZE#OLREC. 


Once you have linked the recovery module, execute the offline 
recovery program, ZC#TRC. In this job control stream, specify 
the type of recovery you want (forward, backward, or quick), the 
point at which recovery starts, and the files to be recovered. The 
system support functions manual, UP-8364 (current version) also 
includes sample job streams for doing this. 


If you use a tape trace file and (due to system failure or some 
other emergency) the tape trace file is left open, you must close 
it before you can use it for recovery. To close the file, use the 
tape copy routine ZE#COPY. Just as with the recovery module, 
you must first link the tape copy module, ZE#COPY, and then 
execute the tape copy routine, ZC#TCP. The IMS system support 
functions user guide, UP-8364 (current version) also provides job 
control for accomplishing these activities. 


If the trace file is on disk and is left open due to a system 
failure, offline recovery can close the trace file by using the 
TRCFILE=CLOSE parameter. 
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8. Additional Features Available 
to Action Programs 


In Section 3 we talked about action programs. We learned how 
they process input messages and produce output messages. We 
also discussed how action programs communicate with IMS to 
accomplish these activities. In this section we learn about 
additional capabilities that IMS provides: 


Special features Continuous output 
Output-for-input queueing 
@ Line disconnect 
Snapshot dump 
UTS downline load 


Screen format services 


Edit table generator 


Vv Vv Vvovr vy Vv VY 


Initiating an OS/3 job 


To use these capabilities, you don’t need to change the basic 
design of the action program. You still define the activation 
record that your program uses to communicate with IMS; and 
Coding for special you follow the rules for coding RPG Il, BAL, or COBOL action 
features programs. The only difference is that you need to do a little 
additional coding in your action program to inform IMS that you 
want to make use of one of these special features. 


How to code for these special features is discussed in detail in 
the IMS action programming manuals. Here, we concentrate on 
@ describing what these features are and how you use them. 
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8.1. CONTINUOUS OUTPUT 


Handling regular output 


Message size 
considerations 


EXCESS 
DATA 


ORIGINAL 


LINE 


All output messages generated by an action program are sent to 
the terminal when the action program terminates - not before. 
Whether a program produces one or 20 output messages, none 
goes to the terminal until the program completes processing. 


When messages go to a terminal, they are sent one at a time, 
beginning with the first message. The operator is informed of 
successive messages by the message waiting light and, when 
ready, acknowledges that message. This continues until all the 
output generated by the program is transmitted. 


The primary reason for generating output in sections is that the 
terminal screen isn't large enough to handle the whole message 
at once. Any single output message generated by an action 
program can never be larger than the terminal screen size. 
Otherwise, it wraps around and is partially lost (Figure 8-1). 




















3325 5185 2575 
E994 957 2775 3500 
ABC B620DING  SUPP1850 3785 
F765 PB115CT INVENT 5765 1158 


PRODUCT NO NO CURRENTLY 
NO. PURCHASED ON ORDER AVAILABLE 








A292 5281 11700 6231 
A331 485 1000 550 
A624 2890 4500 750 
A983 3705 3500 2000 
B247 5500 10800 7500 
B338 385 4000 125 
B765 2215 2050 3045 
C288 1555 2225 1055 
C433 725 1200 2950 
C529 375 545 1875 
D776 3345 2560 3681 
D831 5195 9280 4215 
E444 2210 4450 1110 


IIS 


Figure 8-1. Output Message Is too Large 
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Operator This method of handling output messages works fine if an 

acknowledgement Operator sits at the terminal waiting to acknowledge each 
message waiting signal, if there aren't too many _ output 
messages, and if the data can be analyzed on the spot. 


But what happens when a transaction contains large amounts of 
data for transmission and wants that data available to many 
users , 


Example For example, company ABC wants quarterly sales reports 
incorporating sales information from 10 regions and distributed to 
sales managers, supervisors, and company executives. 


A series of action programs are developed to gather the 
Statistics and the data is processed until the end of the fiscal 
quarter. Two days later at the strategy meeting to discuss 
planning for the next quarter, all interested parties have received 
the data and have had time to study the report. 





The report was easily processed using continuous output. 
Here’s how.... 


Identifying continuous ...when the action programs were designed to process this 

Cuaput report, special codes were included. These codes tell IMS that 
the output message generated by this program is not regular 
output. It is special; it is continuous output. 


Comparing Regular and Continuous Output 


A continuous output message is transmitted when the action 
program terminates, just like reguiar output. Also, a continuous 
output message can't be larger than the size of the terminal 


@ screen. 


Similiarities 
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Differences 


Last message 
transmitted 


Naming a successor 


Example 





Continuous output differs from regular output in that an action 
program can produce only one continuous output message and it 
must be the last message the program generates. That's an 
important point to remember. 


Figure 8-2 shows how an action program produces three regular 
output messages and, finally, a continuous output message. 
When the program finishes processing, the messages are 
transmitted, in the order they were generated, to the terminals. 


The continuous output message must be the last message 
transmitted. The program can produce many regular output 
messages, but the continuous output message must be the final 
message. 


When using continuous output, it is best to send output 
messages that need a response to one terminal and send 
continuous output messages to another terminal. Also, since 
continuous output messages are limited in size when going to a 
display terminal, they are usually sent to a printer terminal. 


ACTION 


PROGRAM 





Figure 8-2. Continuous Output Must Be the Last Message Generated 


There’s another difference . . . a program that generates 
continuous output must name a successor program. The reason 
for this should be obvious. If the first program can generate only 
one continuous output message and that message can't be larger 
than the size of the terminal screen, there has to be some way 
of continuing processing to generate the lengthy report. That's 
where the successor program comes in. 


In Figure 8-3 you see how action program A _ generates a 
continuous output message. The program names a successor and 
terminates. Then, the continuous output message is transmitted 
to the terminal. 
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& Now, the successor program (B) gets control and generates a 
continuous output message. It also names a successor program 
and terminates; and the second continuous output message is 
sent to the terminal. 


The process is repeated with successor program C. 


Naming a successor program allows a _ continuous output 
transaction to continue generating messages for as long as it is 

No operator required required. And this happens without an operator sitting at the 
terminal acknowledging one message after another. In fact, once 
the transaction code that started the transaction is keyed, the 
operator can leave the terminal altogether. IMS transmits each 
message and schedules the successor program without any 
operator intervention. 


ACTION 
PROGRAM 
A 


ACTION 


e@ PROGRAM 
B 


ACTION 
PROGRAM 
Cc 





Figure 8-3. Naming Successor Programs to Continue Generating 
Continuous Output 


The final destination for continuous output is usually not the 
terminal screen. (It's unlikely an operator is going to sit for long 
periods at the terminal watching screenfuls of data.) 


Generating printed Generally, we use continuous output to produce a printed report. 
reports The continuous output message appears on the terminal screen 
but is immediately transmitted to a printer or some other auxiliary 
device attached to the terminal. It might even be sent to a 
cassette or diskette or it might be sent directly to a hard copy 
@ terminal, such as a teletypewriter. 
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But remember, whether the message goes to the terminal or to a 
printer or other auxiliary device, the length of the continuous 
output message transmitted still cannot exceed screen capacity. 
The message always passes across the terminal screen first. 


ACTION 
PROGRAM 





Continuous Output Is Used to Produce Printed Reports 





How IMS Handles Continuous Output 


Let's now look at how IMS handles continuous output as 
compared to regular output. The handling of regular output 
should be quite familiar to you by now, but for a review of how 
IMS handles regular output, see Sections 3 and 7. 


Handling regular With regular output, the action program terminates and the 
output messages message is transmitted to the terminal. Then, depending on the 
type transaction structure the program specified, IMS either waits 
for more input from the terminal or schedules a successor 


program. 
Handling continuous The process for continuous output is slightly different. When the 
output continuous output message is transmitted, IMS doesn't expect 


any input from the terminal and, more than likely, no operator is 
there. However, IMS does wait for a response from the terminal 
receiving the continuous output. 
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Response from ICAM The response comes from ICAM, the communications network. It 
informs IMS whether or not the message was_ successfully 
delivered to the terminal or printer. This response is the delivery 
code. Once IMS receives this code it transmits it to the 
successor program (B). 


ACTION 
PROGRAM 
A 


ACTION 


PROGRAM 
B 





é& Using Continuous Output, ICAM Sends a Delivery Code to IMS 
Processing the delivery The successor program begins processing by examining the 
code delivery code. If the code indicates successful delivery, the 


successor program generates its continuous output message. lf 
the code says that the continuous output message wasn't 
successfully transmitted, the successor doesn’t generate a 
continuous output message. Instead, it tests to see what went 
wrong and attempts to correct the problem. Once the problem is 
corrected, the successor program reschedules_ the _ first 
continuous output program so that it can attempt once again to 
transmit the continuous output message. 


Generating more When the delivery code says the first continuous output message 

continuous output was successfully delivered, the successor transmits its 
continuous output message. IMS again waits for a response from 
ICAM on the status of the message. If there’s still more output 
to be printed, IMS schedules the successor and sends it the 
delivery code. This process is repeated as long as there is output 
to be printed. 
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Devices supporting 
continuous output 
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The following terminals and auxiliary devices can receive 
continuous output: 


UNISCOPE 100 display terminals 

UNISCOPE 200 display terminals 

Directly connected workstations 

UTS 10, 20, 40, and 400 terminals 

DCT 500 terminals operating in teletypewriter mode 
DCT 1000 terminals in interactive mode (Series 90 only) 


TELETYPE* models 28, 33, 35, 37, and 38 


Vv VT Vv vo Vv Vv VT 


Auxiliary devices at the UNISCOPE 100 or 200 Display 
Terminals or Universal Terminal System 400 (UTS 400). 
These are (see NOTE): 

- Communications output printers (COPs) 

- Terminal printers (TPs) 

- Model 610 Tape Cassette System (TCS) 

- 8406 Diskette Subsystem 

NOTE: 


Both TELETYPE and DCT 500 terminals always _ provide 
successful delivery codes unless the terminal or line goes down. 


When you inform IMS that you're transmitting continuous output 
to an auxiliary device, there are numerous options you can 
choose from to specify how it is transmitted. Each of these 
options has a special code. The action programming manuals 
describe these options in detail. 


“Trademark of Teletype Corporation 
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To summarize, continuous output is very useful for generating 
lengthy reports. Once IMS receives a transaction code that starts 
the continuous output transaction, IMS and the action program 
are totally in control. From that point on, no operator intervention 
is necessary to have one output message after another 
transmitted to a terminal or auxiliary device attached to the 
terminal. A continuous output transaction continues as long as 
each action program names a successor to keep generating 
continuous output. 


To use the continuous output feature, you _ specify 
CONTOUT=YES in the OPTIONS section of the IMS 
configuration. And you include some additional code in your 
action program to inform IMS that you're generating a special 
type of output message. 
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8.2. OUTPUT-FOR-INPUT QUEUEING 


Defining output-for-input 


queueing 


Example 


With a screen bypass 
device 


Another special feature of IMS is output-for-input queueing. 
This feature is also concerned with output messages; it starts an 
IMS transaction at another terminal. Let’s see how this works: 


ACTION 
PROGRAM 
A 





Using Output-for-Input Queueing to Start a Transaction at another Terminal 


Terminal 1 enters a transaction code that calls action program A 
which begins processing and tells IMS it’s generating an output 
message using output-for-input queueing. IMS takes that message 
and uses it to start a new IMS transaction at terminal 2. 


You're probably wondering why terminal 2 just doesn’t start its 
own transaction by having an operator enter a transaction code 
there. Well, there are a couple of reasons. 


First, some devices, such as the UTS 400 screen bypass device, 
are defined as terminals but don’t have any physical apparatus 
(such as a keyboard) for entering data. The only way they can 
receive input is if it is transmitted from somewhere else, such as 
an action program. 


This is one example of when output-for-input-queueing is very 
useful. One terminal starts an IMS transaction. The action 
program processing that transaction sends an output message 
using output-for-input queueing to IMS which, in turn, starts a 
new transaction at the screen bypass device. 
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queueing 


Identifying destination 
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Identifying transaction 
code 
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Another situation where output-for-input queueing is frequently 
used is with continuous output. Using output-for-input queueing, 
an action program can send an output message that starts a 
transaction that prints continuous output at another terminal in 
your installation or at a remote site miles away. 


ACTION 
PROGRAM 


Using Output-for-Input Queueing to Start a Continuous Output Transaction 


Using the Output-for-Input Queueing Feature 


There is special code you include in your action program to use 
output-for-input queueing. The action programming manuals 
discuss this in detail. This code informs IMS that the output 
message generated is to be handled in a special way - as an 
output-for-input queueing message. 


The action program also tells IMS the destination for the 
message - where it wants the new transaction to begin. In our 
example, it is a UTS 400 screen bypass device although it could 
be any terminal in the IMS network. Since this message will start 
a transaction at the screen bypass device, the program must also 
provide a valid transaction code - one that tells IMS what action 
program to schedule to process the transaction. 
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Special handling 


IMS internal processing 


Handling Output-for-Input Queueing Messages 


You don’t see output-for-input queueing messages at the terminal 
like you do regular output messages. Because the output-for-input 
queueing message automatically starts a transaction, there’s no 
reason to display a message; the transaction automatically starts. 


When the action program in process sends an output-for-input 
queueing message, it is queued for passage to the destination 
terminal. When the action program terminates, the message is 
sent to the successor action program which starts a transaction 
at the destination terminal. The following illustration shows how 
IMS handles output-for-input queueing. 


ACTION 
PROGRAM 





Handling of Output-for-Input Queueing Output Message 


When you think about it, this makes a good deal of sense. If 
you're using output-for-input queueing to begin with, you either 
have a screen bypass device as the destination terminal with no 
display device or you have a terminal with no operator. That is 
the purpose of using output-for-input queueing in the first place. 
So, there really is no point in transmitting the output message to 
the destination terminal. There's no one or no way to 
acknowledge it. What is important is that the new transaction Is 
to begin there. 


Here’s how that happens. As soon as the action program 
informs IMS that it is creating an output message using 
output-for-input queueing, IMS takes that message and begins 
processing it — before the program ends. The processing is done 
in two steps: 
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Checks destination Checks transaction 
terminal id code 


Checks destination Checks the remainder 
terminal status of the message 


ACTION ACTION 
PROGRAM PROGRAM 





Processing a Message Using Output-for-Input Queueing 





IMS looks at the destination terminal identification code to 
& Validating destination determine if the code is valid. Then, it checks the status of 


terminal i. : é i 
Mata the destination terminal. 


Is the destination terminal available or is it involved in an 
IMS transaction? 


IMS sends all this data back to the program that generated 
the message. If the terminal identification is invalid or if the 
terminal is occupied or down, the program is informed of 
this and can decide what to do next. Obviously, if any of 
these conditions exist, no transaction is scheduled at the 
destination terminal. 





Validating termination IMS checks the transaction code. If the transaction code or 

code any other portion of the output message sent by the action 
program is invalid, IMS cannot schedule the transaction and 
an “INVALID TRANSACTION CODE"’ message is sent to the 
destination terminal. If the transaction code is valid, IMS 
schedules the transaction at the destination terminal. 


Meanwhile, the program that generated the output-for-input 

se) queueing message finishes processing and terminates, and 
the newly scheduled transaction can begin processing and 
generating output to the destination terminal. 
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In summary, you use the output-for-input queueing feature to 
start a transaction at a terminal other than the one you're using. 
To do this, you enter additional code in your action program that 
tells IMS you're producing a special type of output. 


You identify the terminal where the transaction is to begin and 
give the transaction code that starts the new transaction. 


If the message header and transaction code is valid and the 
destination terminal is free, IMS starts the new transaction. 


If some data is invalid or the destination terminal is occupied or 
down, the action program is informed of the problem and takes 
appropriate action. 


To use output-for-input queueing, you specify UNSOL=YES in 
the OPTIONS section of the IMS configuration. If you already 
specified CONTOUT=YES in the OPTIONS section, you have 
automatic support for using output-for-input queueing. 
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8.3. LINE DISCONNECT FEATURE 


The line disconnect feature allows an action program to 
disconnect a single-station dial-in line. By doing this, the action 
program frees the dial-in line for use by another terminal. 


Using the line disconnect feature is easy. IMS. supplies an action 
program that disconnects the communications line for you. The 
program is called HANGUP. When an action program wants to 
disconnect a line, it calls on HANGUP to do it. 


The action program does its processing and generates an output 
message. To use HANGUP, the program must specify E for 
external succession as the termination code and HANGUP as the 
name of the successor program. 


When the current program terminates, IMS sends the output 
message to the terminal and waits for a delivery notice from 
ICAM saying whether the message was successfully delivered. 


ACTION 
PROGRAM 





Disconnecting a Line from an Action Program — Part 1 


Then, IMS schedules HANGUP to disconnect the dial-in line: 


‘ROWON ACTION 
PROGRAM PROGRAM 
HANGUP 


Disconnecting a Line from an Action Program — Part 2 
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Releasing the line 
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When the action program HANGUP gets control, it issues a 
message to ICAM to release the communications line from the 
terminal presently using it. Thus, the line now becomes available 
to another terminal. 


The line disconnect feature is only available in a dedicated ICAM 
network. It is not available to global networks. To get the line 
disconnect feature, specify CONTOUT=YES in the OPTIONS 
section of the IMS configuration. 
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8.4. SNAPSHOT DUMP FEATURE 


One of the most valuable and frequently 
used special features provided by IMS is 
the snapshot dump. 





Defining a snapshot A snapshot dump gives you a picture of what’s happening inside 

dump your computer system when your action program is processing. 
What's even better is that it doesn’t show you everything that’s 
going on but just what directly relates to your action program. 
So, you don't have to sort through a lot of data which has 
nothing to do with your particular application. 


Function The snapshot dump shows all the areas of the activation record 
used by the action program, as well as the action program itself. 
Most importantly, it shows what went wrong with your action 
program. 


To get a snapshot dump, you must run the IMS job with option 
JOBDUMP or option SYSDUMP job control statements. 


A detailed analysis of snapshot dumps is provided in the action 
programming manuals. Here we explain how snapshot dumps 
occur and what you find in a snapshot dump. 


How You Get a Snapshot Dump 


Cause for dump There are four conditions under which you get a snapshot dump: 


An action program abnormally terminates due to a 
This means a program check interrupt occurred 
during the execution of the action program. 


An action program abnormally terminates due to a 
This means that the program went into a loop 
and the program timer ran out. 


» An action program voluntarily terminates by moving the 
to the termination-indicator field of the program 
information block. 


An action program or subprogram requests a snapshot 
dump by issuing the § unction call. (COBOL and BAL 
programs can do this, RPG Il programs cannot). The action 
program then finishes processing. 
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Abnormal termination 


Voluntary termination 


In abnormal termination, the action program has no control over 
whether the program terminates or not. If an action program 
creates an error condition related to IMS, IMS terminates the 
program and sends a message to the terminal identifying what 
went wrong. That’s what happens with program and_ timer 
checks. In these circumstances IMS also provides a snapshot 
dump of the action program. 


In the case of voluntary termination - the third condition - the 
action program is in control. It deliberately terminates itself. You 
must insert special code into the program that tells IMS to dump 
the program so the programmer can determine what went 
wrong. The last condition allows an action program to request a 
snapshot dump and then continue processing. 


What a Snapshot Dump Contains 


Figure 8-4 is a glimpse of a snapshot dump. A dump can go on 
for many pages depending on the length of the action program. 
The figure shows a small portion of the dump for program 
SNPTST. 
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Figure 8-4. Sample Snapshot Dump 
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Contents of Snapshot dumps can contain six general areas: 
snapshot dump 





Gives general information about which 
program was running when the dump 
occurred and what caused the snapshot 
dump. If it is an edited snap dump, you 
also get an allocation map. This is a 
directory that tells you how to find all the 
major portions of the dump and gives an 
address for each section that the dump 
contains. You do not automatically get this 
header section when you have a snapshot 
dump. In multithread you must request it 
by specifying SNAPED=YES. In 
single-thread, you receive no headers with 
the CALL SNAP function. 


Contains both IMS and action program 
registers or just IMS registers, depending 
on what caused the dump. 


Shows the contents of the program 
information block, input message area, 
output message area, work area, 
continuity data area, and defined record 
area when the program terminated. 


Contains the executing load module as it 
existed in main storage at the time of the 
dump. 





Contains data used to control the IMS 
environment. When you get an unedited 
dump, one without a directory, you can 
find the location of every section of the 
snap dump by consulting the thread 
control block. The thread control block 
also contains other valuable data for 
locating the exact cause of program 
failure. 





Contains data related to the terminal that 
initiated the action program. 
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8.5. UTS DOWNLINE LOAD FEATURE 


Definition of downline 
load 


Using IMS load library 


Accomplishing the 
downline load 


Configuration 
requirements 


Destination of downline 
load 


Programs for downline 
load 


You use an action program to load other programs from an IMS 
library into a UTS 40 or 400 terminal. The advantage of doing 
this is that you use the processor capabilities of the UTS to 
process the program, thus freeing main storage of the host 
computer for other activities. 


The program to be loaded must be stored in the system load 
library or in the IMS load library. The actual downline loading of 
the programs is performed during IMS online processing. There 
are two ways to downline load a program: 


Enter the transaction code DLOAD. This activates an 
IMS-supplied action program that does the downline load. 


Write your own downline load action program in COBOL or 
BAL. Downline load action programs in RPG Il are not 
supported. 





To use the downline load feature, you must generate a resident 
communications network and must specify DLLOAD=YES in the 
OPTIONS section of your IMS configuration. 


When you downline load a program, you load it directly into UTS 
40 or UTS 400 main storage or into an auxiliary device attached 
to the UTS terminal (such as a cassette or diskette). Once it is 
loaded to an auxiliary device, you read it into the UTS 400 main 
storage as your application requires. The only _ special 
consideration is that when you downline load directly to UTS 
main storage, the terminal that processes the program must be a 
master or primary UTS 40 or 400 station. 


Programs intended for downline load are written in COBOL, MAC 
80, or PLM. These programs are often designed to edit or 
validate IMS transaction codes or other input messages. If the 
input contains errors, these programs can handle them directly at 
the terminal, before the input is transmitted to the host 
computer. The following illustrates downline loading programs to 
a UTS 400. 
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ACTION 
COBOL/MAC 80 PROGRAM 





Downline Loading Programs for Processing at a UTS 400 


For a detailed description of how to write your own downline 
load action program, consult the IMS action programming in 
COBOL and basic assembly language user guide, UP-9207 
(current version). The DLOAD transaction code is described in 
detail in the IMS terminal users guide, UP-9208 (current version). 
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8.6. SCREEN FORMAT SERVICES 


Defining screen format 
services 


Other formatting 
techniques 


Devices supporting screen 
format services 


Using the screen 
format generator 


Screen format services is a separate software package which 
allows users to create formatted screens. IMS interfaces with 
screen format services to allow action programs to use screen 
formats for input and output messages. 


There are, of course, many ways that action programs can 
format messages. They can use field control characters, field 
format characters, or device independent control expressions. 
However, all of these involve considerable coding. 


Just the opposite is true when you use screen format services. 
Generating formatted screens this way is extremely easy. By 
simply adding a small amount of code to the header portion of 
your output message, you can display formatted screens at the 
terminal. 

Devices Supporting Screen Format Services 

You can display screen formats on the following devices: 

> UNISCOPE 100 (with PROTECT feature) 

> UNISCOPE 200 (with PROTECT feature) 


> UTS 400 (in UNISCOPE mode or operating in native mode, 
with PROTECT/FCC switch set to FCC and control page set 
to XMIT variable) 


> UTS 10, 20, 40 


> Workstations 


How You Create Screens 


To use formatted screens, you must CALLING ON THE 
create them offline. You do this by SCREEN FORMAT 
executing the screen format generator. = 


To execute the screen format generator, 
your operating system must be 
generated in CDM or mixed mode. 
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Using screen format The screen format generator provides a series of menus that 
sneOHS direct you in creating a screen. You assign a specific name to 
each screen you create. You also inform the screen format 
generator whether it is an input-only screen, output-only, or both. 


Among other things, you can define fields as numeric only, or 
alphanumeric. Based on how you define fields, the screen format 
coordinator validates data entered for these fields. 


Storing formatted The screen format generator stores each screen you create in the 
screens system format library (SYS$FMT) or on a disk library you specify. 


When an action program requests a specific screen, IMS calls 
upon the screen format coordinator and it, in turn, retrieves the 
screen from the format library. 


SCREEN 
YOU 
CREATE SCREEN 


FORMAT 
GENERATOR 





Storing Screen Formats 


For more information about screen format services and 
generating your own screens, see UP-8802. 


Using Screen Format Services 
Coding required Using screen format services involves additional coding in your 


action program. In COBOL and BAL action programs you get 
screen format services via CALL functions. 


The specific CALL functions used for screen formatting are CALL 
BUILD and CALL REBUILD: 


CALL BUILD CALL BUILD tells IMS what screen is required to format the 


output message, what variable data is to be inserted into the 
formatted screen, and what option indicators are set. 
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CALL REBUILD 


RPG I! users 


Retrieving a screen 


format 


Building a screen 


Displaying a screen 





CALL REBUILD tells IMS to build an error screen or to 
replace input fields with underlines to prompt the terminal 
operator to make the required entries. In the case of the 
error screen or the underlines, CALL REBUILD lets you put 
out an altered screen, without having to generate an entirely 
new screen. CALL REBUILD cannot be issued for a screen 
format which uses output option indicators. In this case, a 
CALL BUILD should be issued with the appropriate indicators 
set. 


For the error screen, the screen format coordinator replaces error 
fields with blinking characters to show the operator exactly 
where the input error occurred. 


In RPG Il action programs, you build an error screen by using 
option indicators. 


Once an action program requests a screen format, IMS passes 
the format name, the variable data, and the option indicators to 
the screen format coordinator, which retrieves the proper format 
from the format library. IMS then places the format in the output 
message area of your action program or in a dynamic main 
storage area. 


ACTION 
PROGRAM 

ir SCREEN 

SCREEN {12} FORMAT 

FORMAT 7 LIBRARY 


SCREEN 
FORMAT 
BUILT 


Retrieving a Screen Format 


When the screen is complete the screen format coordinator 
inserts the variable data. When the action program terminates, 
the formatted screen, display constants, and variable data, all go 
out to the terminal. Figure 8-5 shows an output screen 
containing display constants and variable data. 
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EMPLOYEE NUMBER: 12345678 
NAME: JOHN DOE 
ADDRESS: 123 OAK ST. 


ALLENTOWN, ;PENNA. 
98765 





Figure 8-5. Output Screen Format with Display Constants and Variable Data 


Using an input screen Often a screen generated by an action program requires input 
from the terminal operator. Figure 8-6 shows a screen that 
requests specific information from the operator. This information 
is used to update a customer file. 


PRODUCT NO: 
QUANTITY: 


@ CUSTOMER ACCOUNT 35618 


UNIT COST: 
REGION: 





Figure 8-6. Screen Format Requiring Input Data 


Validating input When the terminal operator fills in the data requested, IMS 
checks the message for terminal commands. Then, it passes 
control to the screen format coordinator to validate the specific 
entries made. Once this is complete, IMS passes the validated 
data to the input message area of the action program named to 
process it. 


Identifying invalid input When the screen format coordinator detects invalid data, it 
causes the incorrect entries to blink at the terminal. This way the 
operator knows which entries to correct. Once the new data is 
entered and validated, IMS places it in the input message area of 

e the action program to await processing. 
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Configuration 
requirements 


IMS start-up 
requirements 


To use screen format services in your action program, there are 
certain special considerations to take into account at IMS 
configuration. 


First, you must specify the SFS parameter and RESFMT 
parameter in the OPTIONS section of the configuration. Also, 
when specifying the maximum size of the output message area, 
be sure it’s large enough to handle the screen you want to build. 


If you don’t know the size of the resulting formatted screen, the 
action program can request the use of dynamic main storage. For 
more information on this, and other special considerations see 
the appropriate action programming manual. 


For more information on IMS and screen format services, see the 
system support functions user guide, UP-8364, (current version). 


Also, at IMS start-up, there are certain job control statements 
which you must include in the job control stream. These are 
covered in detail in the action programming manuals. 
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8.7. EDIT TABLE GENERATOR 


The last special feature available to action programs that we 
discuss in this section is the edit table generator. As you know, 
the validity of input data is a major concern in an online system. 
Coding validation is a complicated and time-consuming process. 
Using the edit table generator simplifies the procedures. 


Defining the edit The edit table generator is an offline IMS utility available in both 

table generator single-thread and multithread. You use this utility to generate edit 
tables that convert freeform input entered by terminal operators 
into fixed formats required by the action program. Using these 
edit tables, IMS checks this input for data type, value ranges, 
and presence of required fields. 


Using the Edit Table Generator 


Configuration 

requirements Each edit table is associated with an action. When you generate 
an edit table for an action, you specify the EDIT=tablename in 
the ACTION section of your IMS configuration. When the action 
program is scheduled, IMS loads the edit table (from NAMEREC) 
to format and validate input to that program. 

Using the edit table The edit table generator utility is run offline. Input to the edit 

generateor 


table generator is in the form of keyword parameters. These 
parameters define the edit table name, each field of the input 
message to be edited, and the editing criteria for each field. 


A detailed explanation of the keyword parameters entered as 
input to the edit table generator can be found in the action 
programming manuals. 


You can run the edit table utility before or after configuration. All 
output of the edit table generator is written to the named record 
(NAMEREC) file, from where it is loaded at the appropriate time 
by applications management. 


EDIT TABLE EDIT 
INPUT TABLE 


PARAMETERS GENERATOR 
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How Terminal Input Is Edited 


When a terminal operator enters a message for which there is an 
edit table, an IMS component called the expanded input editor 
validates the data according to the edit table and puts it into the 
format the action program requires. 


The editor checks that the transaction code is the initial field of 
the input message, that input fields are the correct length, and 
whether an omitted entry is mandatory. 


ACTION 
PROGRAM 





Figure 8-7 shows input entered at a terminal and the same input 
as delivered to the action porgram. The commas in the terminal 
input are used as field separators. The two commas between 
SMITH and SN show that the operation chose not to enter an 
address field. 


The edit table allows this omission since address was not 
defined as a mandatory field. The editor fills the name field with 
spaces to the length required by the action program, and also 
sends spaces for the omitted address field. 


Note that the terminal operator reversed the order of the fields 
SN and AMT when entering them. Consequently, the edit table 
generator puts them in the order that the action program was 
designed to receive them. Also, the variable data for the AMT 
field is changed to a hexadecimal value according to the 
specifications made to the edit table generator. 
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PAYMT, JOHN D. SMITH, ,SN=123456, AMT=2500 


PAYMT JOHNAD . ASMI THAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
DADADAAAAAAAAOICS 123456 





Figure 8-7. Input Edited According to an Edit Table 
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8.8. INITIATING AN OS/3 JOB 


Reading a job control 
stream 


IMS action programs in COBOL and basic assembly language can 
initiate the reading of a job control stream and scheduling a job 
for execution. They do this by issuing a RUN function call. For 
the format of this function call, see IMS action programming in 
COBOL and basic assembly language user guide, UP-9207 
(current version). 
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9. IMS and Distributed 
Data Processing 


Definition A distributed data processing system allows two independent 
computer systems to communicate with one another. They are 
linked together through telecommunications so that each can use 
the other’s capabilities and data. With distributed data processing 
(DDP), a Series 90 or a System 80 computer can access data on 
any other Series 90 or System 80 computer or send jobs to it. 





DDP System with Electronic Link between Independent Computers 


With distributed data processing, you are able to process IMS 
transactions at a remote computer. We call this capability the 
IMS transaction facility IMS transaction facility. 


To use this facility, you must have two multithread IMS systems 


Requirements : : : , 
in operation - one at your site, and the other at the remote site. 
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9.1. TYPES OF TRANSACTION ROUTING 


Types of routing 


How transaction directory 
routing works 


There are three ways in which IMS can route a transaction to a 
remote system: 


> Directory routing 


Action program routing 






Operator routing 





The terminal operator enters a transaction code that identifies the 
transaction for processing at a particular remote site. This 
transaction code and the site where it is to be processed are 
defined during IMS configuration. 


TRANSACTION 
DIRECTORY 


Dane eee 
wee eee 


TSTOP 


OS/3 IMS 


ACTION 
PROGRAM 





Directory Routing 


IMS sends the transaction code to the remote IMS, which 
handles processing from that point. The remote IMS processes 
the transaction and sends a message back to the terminal 
operator. 


With transaction directory routing, the remote IMS can process 
dialog transactions as well as simple transactions. 
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How transaction program The terminal operator enters a transaction code that initiates a 

routing works transaction at the local IMS system. The COBOL or basic 
assembly language (BAL) action program that is processing this 
transaction issues an ACTIVATE function call to IMS. This 
function call creates a message that initiates another IMS 
transaction at the remote site. 


The remote IMS processes the transaction and sends a message 
back to the originating action program or its successor program 
after a CALL RETURN is issued. With transaction program 
routing, the remote IMS can process only simple transactions. 


ACTION 
PROGRAM 
ACTIVATE 


OS/3 IMS 


ACTION 
PROGRAM 





Action Program Routing 





How transaction operator Operator routing is similar to directory routing. The operator 

HEBER IVOIKS prefixes the transaction code with a routing character followed by 
a period, which identifies the transaction for remote processing. 
The special character is defined in the IMS configuration or at 
IMS start-up and is associated with a remote IMS system. 


The remote IMS processes the transaction and sends a message 
back to the terminal operator. With operator routing, the remote 
IMS can process dialog transactions as well as_ simple 
transactions. 


OS/3 IMS 


@ : ACTION 


PROGRAM 





Operator Routing 
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9.2. CONFIGURING FOR THE IMS TRANSACTION FACILITY 


To use the IMS transaction facility, you must generate an ICAM 
and IMS for the remote and local sites that support distributed 
data processing. 


Configuring for There are special considerations when configuring IMS. You must 
distributed data include: 
processing 





Specifies the size required for DDP buffers and the number 
of concurrent DDP sessions in the GENERAL section. 





Use the LOCAP parameter in this section for a DDP 
transaction directory routing. 





A routing code that defines or redefines a remote host for 
operator routing. You can include the RCHAR parameter in 
the LOCAP section or in the // PARAM LOCAP statement 
during IMS start-up. If you do both, the PARAM statement 
at start-up overrides the RCHAR statement just for that IMS 
session. 


Further information For specific network definition, configurator, and _ start-up 
requirements, see the IMS system support functions user guide, 
UP-8364 (current version). To write action programs for use in a 
DDP environment, refer to the action programming manuals. 


9.3. PROGRAMMING FOR DISTRIBUTED DATA PROCESSING 


There are two aspects of programming for distributed data 
processing transactions: 





You may be writing action programs at the primary IMS (the 
system where a remote transaction is initiated) to initiate a 
remote transaction through action program routing. Only 
COBOL and BAL action programs can _ initiate remote 
transactions. 
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ACTION 


PROGRAMS ACTION 


i (COBOL OR BAL) i PROGRAMS 





You may be writing action programs at the secondary IMS 
(the system where a remote transaction is processed) to 
process a remote transaction initiated by operator, directory, 
or action program routing. COBOL, RPG Il, and BAL action 
programs can process remote transactions. So can UNIQUE. 





ACTION 
PROGRAMS 





Initiating a Remote Transaction from an Action Program 


In a program-initiated remote transaction, you make the decision 
whether to route the transaction to a remote system on the basis 
of some data the terminal operator enters or perhaps something 
you discover when you access your files or make computations. 


Initiating remote You initiate a remote transaction by identifying the remote IMS 
transaction system (locap-name) in the output message header, building a 

message containing a transaction code in your output message 
External succession area, and issuing an ACTIVATE function call. You must terminate 
required your action program externally, naming a successor program at 


your local IMS system. Of course, you can reschedule the same 
action program as the successor. 
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SSeS 


Processing response 
message 


Similar to 
processing local 
transaction 


Receiving input 
message 


Determining 
source of remote 
transaction 


Operator-initiated 
transaction 


Program-initiated 
transaction 


General restrictions 


SEND function restriction 





Action programs at the remote IMS system process your 
message and send a response. Your successor program receives 
the response message in its input message area. You can then 
send an output message to the originating terminal, or you can 
issue another ACTIVATE call to initiate another remote 
transaction. 


Processing a Remote Transaction at the Secondary IMS 


There is little difference between the way you process a remote 
transaction and the way you process a local transaction. You can 
use the same action programs to process both local and remote 
transactions. 


When the transaction begins, you receive an input message 
starting with a 1- to 8-character transaction code, just as with a 
local transaction. 


You can determine which remote IMS system initiated the 
transaction by testing the source-terminal-id field of the input 
message header. You determine whether the transaction was 
initiated by an operator (either operator or directory routing) or by 
an action program by testing the DDP-mode field of the program 
information block. 


You can use any type of action program succession with 
operator-initiated transactions. Once the transaction begins, the 
IMS transaction facility establishes a communications link which 
stays in effect until the transaction ends. When you use external 
succession, the terminal operator receives and responds to your 
output messages without entering any additional codes. 


When the remote transaction is initiated by an action program, 
you send an output message to the originating action program's 
successor, which in turn sends an output message to the 
terminal. You must use normal termination when returning the 
output message. 


There are a few general restrictions on processing remote 
transactions: 


You cannot use the SEND function to output a message to 
the originating terminal (or any terminal at the remote IMS). 
However, you can use the SEND function to output a 
message to a terminal at your local IMS. 
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Continuous output 


ie You cannot send continuous output to the originating 
restriction 


terminal. Again, you can use the SEND function to initiate 
continuous output at a local terminal using output-for-input 
queueing. 





Auxiliary device 
restriction 


You cannot send output to an auxiliary device attached to 
the originating terminal. However, you can output to local 
auxiliary devices using the SEND function. 





Screen formatting 


You can send screen-formatted messages to the originating 
restriction 


terminal in operator or directory routing, but not to the 
Originating action program in action program routing. 





9.4. PROCESSING REMOTE TRANSACTIONS AT THE TERMINAL 


Operator-initiated There are two types of operator-initiated transactions: 


transactions 
1 > Directory-routed transactions 
2 > Operator-routed transactions 


Directory routing You initiate a directory-routed transaction the same way as other 
transactions, because the transaction code itself tells IMS where 
to route the transaction for processing. The transaction code is 
associated with the remote system by the LOCAP parameter in 
the configurator TRANSACT section. 






Operator routing In operator routing, you decide which remote system will process 
the transaction by entering a route code, followed by a period, 
then the transactions code. For example, to initiate a UNIQUE 
transaction, you might enter: 


*,OPEN CUSTFIL 


The route code is associated with the remote system by the 
RCHAR parameter in the configurator LOCAP section or the 
PARAM LOCAP statement at start-up time. 


Action program The third type of remote transaction routing — action program 
eeenng routing — is not initiated by the terminal operator. You initiate a 
local transaction, which in turn initiates the remote transaction. 
However, you should be aware that a remote transaction may be 
in process while you are waiting for a response to your input 


& message. 
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Standard 
terminal commands 


Master terminal 
commands 


Terminal commands 
that can't be used 


Remote UNIQUE 
transactions 


Other IMS transactions 
not supported 





Using Terminal Commands in Remote Transaction Processing 

















ancels a remote transaction 





Puts your terminal in test mode so that files at the 
emote system are not affected by update functions 


estores your terminal to normal mode 





Resends the last output message from the action 
rogram at the remote system 


uspends output to your terminal 


Releases the hold on output to your terminal 





huts down the local IMS system. Remote transactions 
re allowed to continue during the shutdown time-out 
eriod the same as local transactions. At the end of the 
ime-out period, they are aborted. 





erminates the local IMS system immediately. Local and 
emote transactions are aborted. Files at both the local 
nd remote systems may need to be recovered 


Other master terminal commands and the ZZMCH_ standard 
terminal command, cannot be used in the remote transaction 
processing environment. 


IMS-Supplied Transactions 


As we mentioned before, you can route UNIQUE transactions to 
a remote system by entering a route code, followed by a period 
and the OPEN command. Once you start the UNIQUE transaction, 
you process it the same way as a local UNIQUE transaction. You 
don’t enter another route code unless you enter the CLOSE or 
ZZCNC command to end the transaction or the transaction 
abnormally terminates. 


Except for UNIQUE, you cannot route IMS-supplied transactions 
to remote systems. 














UP-9205 





IMS/DMS interface 


Setting up a data base 


Data base start-up 


SPERRY UNIVAC OS/3 10-1 
IMS CONCEPTS AND FACILITIES 


DATA BASE COMMUNICATIONS 


10. IMS Access to DMS 
Data Bases 


The IMS/DMS interface allows IMS users to access OS/3 data 
base management system (DMS) data bases. This provides IMS 
users with the structural flexibility and powerful access 
mechanisms available to data base management systems. 


ACTION 


PROGRAM 





Of course, to access a data base, you must first have set one 
up. The procedures for doing this are described in the DMS 
system support functions user guide/programmer reference, 
UP-8272 (current version). 


In addition, there are statements you include in the job control 
stream to start up your data base management system when it 
interfaces with IMS. For a complete discussion of these 
statements, as well as a detailed description of the IMS/DMS 
interface, consult the IMS/DMS interface user guide, UP-8748 
(current version). 


Here, we familiarize you with how you, as an IMS user, can take 
advantage of data base capabilities. 
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10.1. COMMUNICATING WITH A DATA BASE 


Data manipulation 
language 


COBOL action programs communicate with the data management 
system (DMS) through a special data base access language, 
called the data manipulation language (DML). DML statements 
resemble conventional COBOL programming statements. You 
embed DML statements in COBOL action programs. 


RPG Il and basic assembly language (BAL) action programs can 
access a data base only through IMS defined files. You include 
special clauses in the data definition to access a data base. You 
can also use UNIQUE to access a data base through defined files. 


10.2. COBOL/DML ACTION PROGRAMS 


Required entries 


Data base terminology 


Defining a schema 


Defining a subschema 


Defining a device media 
control language 


You write a COBOL action program that accesses a DMS data 
base as you would a conventional COBOL action program with 
these additions: 


A schema section with an INVOKE statement in the data 
division. 


A working-storage section in the data division. 


Data manipulation language (DML) statements in the 
procedure division. 


INVOKE Statement 


The INVOKE statement identifies the schema, subschema, and 
device media control language modules. They describe the 
physical and logical structure of the data base as set up by the 
data base administrator. 


The schema is the global view of the data base's logical 
structure. It is a total picture of the logical relationships shared 
by data in the data base. 


The subschema is a logical view of a segment of the data base. 
It is a portion of the schema used by a specific application. 


The device media control language (DMCL) module describes 
the physical structure of the data base. It identifies the location 
of data in the data base. 
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Working-storage Section 


Defining a data base To communicate with DMS, the INVOKE statement provides for a 

management data base management communications area (DMCA) where 

ee ee control information between IMS and DMS is exchanged. This 
communications area is set up in the working-storage section or 
linkage section of the action program. DMS also inserts record, 
set, area names, and other data into this section. 


DML Statements 


Entering DML statements The DML verbs that access the data base are placed in the 
procedure division of the action program. Because you're 
combining the capabilities of an IMS action program and the DMS 
data manipulation language (both having procedure division 
requirements), you must observe a combination of procedure 
division rules that conform to both systems. For a complete 
description of these rules, consult the IMS/DMS interface user 
guide, UP-8748 (current version). 


Initiating data base The first DML statement in your initial action program following 

communication the COBOL MOVE statement must always be an IMPART 
statement. This statement registers the run unit with the data 
base management system. With the successful execution of the 
IMPART statement, the data base management system opens 
the applicable data base areas. 


DML formats Once this is done, you can use nearly all the DML verbs to 
accomplish the record accessing capabilities you require. You'll 
find the formats for data manipulation language verbs in the DMS 
data manipulation language user guide/programmer reference, 
UP-8036 (current version). 


Ending data base When the IMS transaction is complete, you use the DEPART 
communication statement to end communication with the data base management 
system. If, however, you want to continue communication with 
the data base beyond the length of a single action program, you 
terminate the current program with an UNBIND statement. The 


Communication with succeeding action program then issues a BIND statement to 
successor program continue IMS/DMS intercommunication without interruption. 

Status and rollback In addition to the DML verbs, you also include in the procedure 
function division the sections for handling DMS status reports and DMS 


rollback. The status section provides the capability of determining 
whether or not data base access was successful. The rollback 
section provides for recovery of data base files. 
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10.3. DATA DEFINITION USING A DATA BASE AS SOURCE 


Creating defined files 


Using data base files 


Creating a DML/data 
definition 


You write a data definition to create a defined file in IMS. 
User-written action programs and UNIQUE can access defined 
files. The defined record management component of IMS 
constructs defined files from elements of existing disk files. 


The IMS/DMS interface expands the capabilities of defined record 
management. It allows IMS to use a DMS data base subschema 
as a source for creating defined records. In this way, defined 
record management can construct defined records from DMS 
data base records, as well as from conventional files. 


Action programs and terminal operators are not aware that the 
defined records are derived from data base records. The 
user-written action programs and UNIQUE do not change; they 
still access defined records. But now, defined records, in turn, 
access a data base. 


To create defined records which access a data base, you must 
construct an IMS data definition. Embedded in the data definition 
are special DML clauses that build data base relationships (such 
as owner and member) into the data definition. 


Like the COBOL/DML action program, the data definition issues 
an INVOKE statement that identifies the schema, subschema, and 
device media control language module. In the definition division 
of the data definition you describe the defined record. The 
formats include special data definition clauses for the IMS/DMS 
interface. For a complete discussion of these formats, consult the 
IMS/DMS interface user guide, UP-8748 (current version). 


10.4. PREPROCESSING 


Preprocessing 
requirement 


When your COBOL action programs and data definitions contain 
data manipulation language statements or syntax, they must be 
preprocessed before they are submitted to the COBOL compiler 
or data definition processor. 


Figure 10-1 illustrates the preprocessing and compilation order 
required before linking your COBOL/DML program. Figure 10-2 
illustrates the preprocessing and data definition processing for 
the data definition. 
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DML/COBOL DATA MANIPULATION 
ACTION PROGRAM LANGUAGE 
SOURCE CODE PREPROCESSOR 


COBOL PROGRAM 
COMPILER LINKAGE 


IMS LOAD 
LIBRARY 


Figure 10-1. Sequence for Preprocessing and Compiling a COBOL/DML Program 





DATA 
DATA MANIPULATION DATA 
DEFINITION LANGUAGE DEFINITION 


PREPROCESSOR PROCESSOR 
DATA 


DEFINITION 
RECORD 


DIAGNOSTIC 
LISTING 


Figure 10-2. Creating a Data Definition Record 


10.5. CONFIGURATION CONSIDERATIONS 


Required parameters 


To communicate with a data base, there are certain parameters 
to include in your IMS configuration. You must: 


Link the DMS modules to IMS by specifying DMS=YES in 
the OPTIONS section of configurator input. 


Configure COBOL action programs as shared for better 
performance in the multithread environment; specify 
TYPE=SHR in the PROGRAM section and SHRDSIZE=n 
(shared program size) in the ACTION section of configurator 
input. 
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11. Batch Processing 
of Transactions 


Definition The batch processor is an optional component of IMS. It enables 
you to enter input for IMS transactions in card format instead of 
through a display terminal and provides direct output to a printer 
or printer file. You can process batch transactions online (with 
other IMS programs using the normal terminal communications 
network) or offline (without an active terminal network). 


Uses for batch can be a very useful tool. You can use it to: 





Processing 
b Print a file at the end of a day's production. This is 
& particularly convenient for reviewing files that undergo 
massive updating. 

> Print a defined file that you created from your user file. This 
activity is not practical in normal operations from a display 
terminal. 

b Test UNIQUE-based file query and update dialogs designed 
for routine use at production terminals, as well as test 
user-written action programs that your operators initiate as 
transactions during normal production. Printed output listed 
by the batch processor reproduces all input and output 
messages and provides a permanent hard-copy of each 
transaction. 

Example Figure 11-1 illustrates the printed output resulting from a batch 


transaction using UNIQUE. 


Note that both input and output messages are displayed, as well 
as an error message when the operator attempts another MORE 
LIST command after the entire contents of the file has already 
been displayed. 
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OPEN 













* CROHA 

* CUIBA 
OUTPUT 

* DEINS 


* FAILA 








* LO2SC 


* PEIPS 
















* REIBA 





OUTPUT * RI4CL 
* ROICS 
* SHICA 


* SUSMH 


TOVFR 


END OF ion} 
| TRANSACTION f CLOSE 


1* 


Figure 11-1. 


** IMS READY ** 
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// PARAM IN=BATCHIN/IN 
READING SOURCE MODULE BATCHIN FROM FILE IN 


OPEN CUSTOMR 


COMPLETE 


INPUT tonne MORE LIST 


* CUST-ID 
BALANCE -DUE 


75. 


89. 





78/06/07 


* CUST-ID NAME 
BALANCE - DUE 


DUE - IN- VALUE 
CREST PUB 


00 0.00 


CUMBERLAND C1UB 


-00 0.00 


DEW DROP INN 


-25 0.00 


FARRAH'S DEN 


-00 0.00 


NAME 
DUE -IN-VALUE 
LOST CLIPPER 


-00 0.00 
PERRY'S PUB 
-00 0.00 


RED LANTERN 
35 0.00 
RITTER'S ROOST 


00 0.00 


ROYAL NIGHTCLUB 
60 0.00 
SHAMROCK PALACE 


00 0.00 


SUPPER CLUB 


- 00 0.00 


TOWNHOUSE CAFE 
@.00 


INPUT enti £1 OSE CUSTOMR 
COMPLETE 


78/06/07 


08:17:19 


ADDRESS 


YTD - VOLUME 


6 HIGHLAND AVE. 
0.00 
111 BAY AVE. 
0.00 
13 NITEFALL ST. 
76.25 
16 LION ALLEY 
243.19 


ADDRESS 


YTO - VOLUME 


25 SAIL CIRCLE 
0.00 

162 PLANK ST. 
9.00 

15 BACK ALLEY 
75.35 

46 CHICKEN LA. 
0.00 

147 CASTLE ST. 
89.60 


121 CLANCY AVE. 


0.00 

57 MAIN HWY. 
0.00 

19 FRENCH RD. 
0.00 


08:17:32 


MORE 
CITY-STATE 


CREST CITY, PA. 


PORTSIDE, N.J. 


LIGHTHOUSE, PA. 


HILLSIDE, PA. 


MORE 
CITY-STATE 


HARBOR, N.J. 


PERRYVILLE, PA. 


LEGALTOWN, N.J. 


BARNYARD, PA. 


BLUEBLOOD, PA. 


IRISHTOWN, PA. 


OVERTON, N.J. 


SPURNBURG, PA. 





ERROR 


UNIQUE Transaction Listed by Batch Transaction Processor 


LIST. 
ZIP 


16331 
08131 
16217 


16314 


16212 
08412 
16013 


16310 





16225 


08015 


16611 





LIST. 
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11.1. PROCESSING IN THE BATCH ENVIRONMENT 


Batch transactions are processed as if they originate from one or 

more actual terminals. Based on the input you provide to the 
Creating cofigurator in the BATCH parameter, IMS creates one or more 
pseudoterminals pseudoterminals to initiate batch processing. 


When processing begins, the batch processor responds to input 
from the pseudoterminals and lists output on a print file assigned 
to each pseudoterminal. This output is a step-by-step record of 
each transaction initiated. 


Types of transaction The batch processor handles (in online or offline mode) the 
supported following four types of transactions: 








, Other transactions - initiated by a 1- to 8-character 
transaction code, such as those initiating user-written action 
programs 









Two of the standard terminal commands: ZZTMD and ZZNRM 


> SWTCH transaction - To send output to an online terminal 
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11.2. PREPARING FOR BATCH PROCESSING 


BATCH parameter 


Single and multithread 
batch operations 


Considerations when 
executing IMS 


Card input 





To include batch processing modules in your IMS configuration, 
specify the BATCH parameter in the NETWORK section. This 
parameter has two forms: 


BATCH=YES 





When you specify BATCH=YES, IMS generates one batch 
pseudoterminal to initiate batch transactions. When you specify 
BATCH=n, IMS generates the number of pseudoterminals 
designated by n. 


In a single-thread environment, you can only process one batch 
transaction at a time. Consequently, BATCH=YES or BATCH=1 
is your only option. On the other hand, in a multithread 
environment, it is possible to process up to four batch 
transactions simultaneously. 





In addition to specifying the BATCH parameter at IMS 
configuration, there are certain modifications you must make to 
the IMS execution run stream. They are: 


b Assigning source module input files or embedding input 
source data in the control stream. 


Assigning printer files. 
Inserting the PARAM BATCH statement and_ optional 


PARAM IN statements to control the batch processor (these 
must always follow any other PARAM statements present). 





You can enter input to the processor on cards if you choose; 
simply include card-images directly in the IMS execution control 
stream. You place the cards after the PARAM BATCH statement. 
They can be interspersed among the PARAM IN statements. 
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@ Sometimes it is more convenient to record the card-images of 
Disk input your input messages on disk and place them in disk library files 

for easy reference. When you choose this option, you must 

name the source module input files during the IMS execution job. 


Using the PARAM IN You name them using the PARAM IN statement which identifies 

statement the module name and the file where it resides. PARAM IN 
statements follow the PARAM BATCH statement. There can be 
as many PARAM IN statements (or none) as you choose. 





Purpose of printer file You must have one printer file for each batch pseudoterminal. 
Each printer file records the output of batch transactions initiated 
at its pseudoterminal. 





Using the PARAM BATCH You specify the PARAM BATCH or PARAM BA statement to 

statement designate the type of batch processing you require (NO, OFFLINE, 
or ONLINE). The default is PARAM BA=NO which indicates batch 
processing is not supported. 





@ Offline batch processing is processing done without an active 


communications network. 





Online batch processing is processing with an_ active 


communications network. 
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11.3. CONTROLLING BATCH PROCESSING 


Controlling offline 
processing 


Controlling online 
processing 


Performance 
considerations 


Parameter 
specifications 


Forms of the ZZBTH 
command 


Module name format 


ZZBTH ALL format 





Offline IMS batch processing occurs without an_ active 
communications network. All processing is controlled by the IMS 
execution job control stream. You specify the PARAM 
BATCH= OFFLINE statement followed by PARAM IN statements 
identifying input Source modules and/or embedded data sets. 
The order in which these appear in the control stream determines 
the order in which the batch processor processes them. 





Online batch processing requires an active communications 
network. You control online batch processing from the master 
terminal using the ZZBTH master terminal command. By entering 
this command, the terminal operator controls which source 
modules are processed and when. 


Batch processing conducted online can adversely effect the 
performance of other IMS terminals. It is best to confine batch 
processing to slow periods or just prior to IMS shutdown. The 
number of batch transactions in progress also effects IMS 
performance. 


For online batch processing specify the PARAM BATCH=ONLINE 
statement. It is optionally followed by PARAM IN statements and 
embedded data sets. No batch processing is performed until the 
first ZZBTH master terminal command Is entered. 





The | command has several forms. They are: 
ZZBTH /module-name, file-name 

*[,ALL] 

CANCEL 

PAUSE 

RESUME 


You must identify at the terminal the name of the input source 
module. 


Specifying the ZZBTH *[,ALL] format allows you to use source 
data identified by PARAM IN statments and/or embedded data 
sets. Only this form allows for source input from the job control 
stream. Otherwise, source input must be specified using the 
ZZBTH module-name.file-name format. 
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@ When you enter the ZZBTH command at the master terminal and 
the batch processor recognizes batch input, the message BATCH 
INITIATED is sent to the master terminal and processing begins. 


Single and multithread With single-thread IMS, only one ZZBTH command can be 

processing entered at a time. When processing is complete, you can enter 
another ZZBTH command. In multithread IMS, several ZZBTH 
commands can be _ processed sumultaneously, up to the 
maximum number specified in the BATCH=n keyword parameter 
(11.2). 


Diagnostic message lf the master terminal operator attempts to enter a ZZBTH 
command in excess of the maximum number of batch modules 
that can be processed concurrently (or a single-thread operator 
enters a second command before the first is complete), IMS 
returns a diagnostic message: 


TOO MANY ZZBTH COMMANDS ENTERED - COMMAND 


IGNORED. 
ZZBTH CANCEL format The ZZBTH CANCEL command cancels a batch transaction 
ZZBTH PAUSE format currently in progress; the ZZBTH PAUSE command allows you to 


ZZBTH RESUME format suspend batch processing temporarily; ZZBTH RESUME restarts 
the batch transaction after a suspension. For further details on 
using the ZZBTH master terminal command, consult the IMS 
terminal users guide, UP-9208 (current version). 


11.4. ERROR MESSAGES AND RECOVERY 


Error messages In addition to the error messages generated by IMS (which the 
batch processor includes in its output listing to each 
pseudoterminal), the batch processor creates a set of its own 
error messages. It sends these messages to the master terminal 
or includes them in the output lising for the pseudoterminal. For a 
complete listing of batch processing error messages, see the IMS 
system support functions user guide/programmer reference, 
UP-8364 (current version). 


Recovery For file recovery during batch processing, you enter a DLMSG 
input message via cards. You supply one DLMSG card-image for 
each batch pseudoterminal. The DLMSG command provides in 
print the last output message generated by each transaction. 
Using this output, you can decide where the system aborted and 
determine where to restart your batch processing. 

















UP-9205 SPERRY UNIVAC OS/3 12-1 
IMS CONCEPTS AND FACILITIES 


DESCRIBING DEFINED FILES AND RECORDS 








12. Defined Files and 
Data Definitions 


12.1. COMPARING CONVENTIONAL AND DEFINED FILES 


Describing. conventional You are obviously familiar with conventional files. These are the 
files data files you normally access in your application programs. You 
designed these files; you know what records they contain and 
the size and location of fields in the records. In addition, you 
know their physical location — that is, exactly what disk they're 
on. Consequently, whenever you want to retrieve a record, you 
simply specify what disk it is contained on and its file name. IMS 
file management, in conjunction with data management, locates 
& the record and brings it into your program. 


Pumbeaet denned Hiss Defined files are built from conventional files. They provide a 
means of creating a file for a particular application from existing 
data without having to physically create the file. 


Example Figure 12-1 shows that the defined record PAYROLL was 
derived from the conventional record PERSNEL. The defined 
record PAYROLL, contains only four of the eight fields present in 
the conventional file record. Thus, we have drawn records from 
the conventional file PERSNEL to create a new defined file called 
EMPINFO. 


NAME | ADDRESS PHONE DEPT. } POSITION | SALARY 


Figure 12-1. Creating a Defined Record from a Conventional Record 
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No physical location 


Description of the 
defined file 


Advantages of defined 
files 


What makes a defined file different? The difference is that the 
defined file never physically exists. 


The defined file in Figure 12-1 doesn’t occupy any physical 
location on disk. The only thing that exists is a description of the 
defined file which you provide using what is called a data 
definition. This description provides IMS _ defined record 
management with enough data to go out to your conventional 
files and pull in the fields required to make up the defined record. 


Defined files can be very useful. For one thing, they give you the 
flexibility of data base management without the tremendous 
amount of time and effort that creating a data base requires. 
Also, by using defined files, you can avoid unnecessary repetition 
of data and waste of disk space. And, at the same time, you're 
able to combine data from several conventional files and 
manipulate that data so that it is best suited to a particular 
application. 


12.2. CREATING DEFINED FILES 


Creating a data definition 


Using the data 
definition language 


Running the data 
definition processor 


Output of the data 
definition processor 


Preparing the NAMEREC 
file 


To use defined files you must create a data definition. The data 
definition is a description of the defined file. It tells IMS what 
conventional file or files you're drawing data from. 


You write a data definition using the IMS data definition 
language. This language resembles COBOL. Once written, you 
submit the data definition to an IMS utility program called the 
data definition processor. (Figure 12-2). 


The data definition processor: 
Creates a data definition record in the NAMEREC file. 


Produces a printed description of the defined file and a 
diagnostic listing. 


Since the data definition is stored on the NAMEREC file, you 
must initialize it (using the NAMEREC file utility or the configurator 
before running the data definition processor). 




















UP-9205 SPERRY UNIVAC OS/3 12-3 
IMS CONCEPTS AND FACILITIES 


DESCRIBING DEFINED FILES AND RECORDS 














DATA 
DEFINITION 
PROCESSOR 


DATA 
DEFINITION 





Figure 12-2. Creating a Data Definition 


12.3. DESCRIBING DEFINED FILES AND DEFINED RECORDS 


In the data definition, you describe the structure of the defined 
file and the defined record it contains. 


Types of defined files A defined file can be structured in various ways. It can: 


& Be identical to an already existing conventional file. The 
most common reason for doing this is for use with UNIQUE. 


Describe the conventional file differently . 

Combine data from more than one conventional file. 

With each run of the data definition processor you create one 
defined file. This defined file can contain several different types 


of defined records. 


Types of defined records A defined record can be structured in various ways. It can 
consist of: 


All or part of a record from one conventional file 


All or parts of several records from the same conventional 
file 


All or parts of several records from different conventional 
files. 
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Assigning an identifier 


File restrictions 





For each type of defined record you describe, you include an 
identifier. The identifier is a portion of the record key of the 
conventional record from which the defined record is being 
created (Figure 12-3). These identifiers (or mini-keys) serve to 
locate the data in your conventional files. 


CARROLL. .£.°.C.” 
aaa 


q CARROLLAEACAAAAAAAAA 367AMONTEVERDIA PA 17727 2125377576 529041 MICRO-COMPUT AA$32,785,00 





Figure 12-3. Using the Identifier to Locate the Conventional Record 


Because IMS is dependent upon linking defined records to 
conventional records through the use of record keys, you can 
build defined files from indexed files (ISAM), multiple indexed 
random access method (MIRAM), or a database subschema using 
the IMS/DMS interface. You can only use nonindexed files (DAM 
or MIRAM) when they are combined with indexed files or a 
subschema. 
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Function of defined 
record management 


Using the defined 
record area 





12.4. ACCESSING DEFINED RECORDS 


Each time an action program calls a defined record, defined 
record management (a component of IMS _ file management) 
checks the NAMEREC file for the description of the defined 
record. The identifier statement, which is part of your data 
definition, is used to locate the conventional records that contain 
the data used in building the defined record. Figure 12-4 
illustrates this process. 


NAMED 
RECORD 
(NAMEREC) 
FILE 


v= 


FILE 
MANAGEMENT 


ACTION DEFINED DATA 


\ 
PROGRAM RECORD | MANAGEMENT CONVENTIONAL 
MANAGEMENT , FILE 


(DRM) ' 


Figure 12-4. Accessing a Defined Record from an Action Program 


Defined record management uses the defined record area as a 
work area during this process of retrieving defined records. 


The defined record area is part of the activation record. When an 
action program intends to access defined records, it must set up 
a defined record area. Once the defined record is retrieved, 
defined record management makes it available to the action 
program for processing. 
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12.5. DEFINED FILES AND UNIQUE 


Defined files required 
by UNIQUE 


UNIQUE is the IMS-supplied set of action programs for file 
retrieval and updating. It accesses defined files only. 
Consequently, to use UNIQUE you must create defined files. 
Often, to get online quickly, you can create defined files that are 
identical to your conventional files. Thus, you can perform limited 
transaction processing with UNIQUE while writing and testing 
your own action programs. 


For a detailed description of how to use UNIQUE, consult the 
IMS data definition and UNIQUE user guide, UP-9209 (current 
version). 
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12.6. CREATING A DATA DEFINITION 


Structure of a data Figure 12-5 shows the overall structure of a data definition. It 
definition contains: 


> Identification Division 
Assigns a unique name to the data definition 


> Data Division 
Describes the conventional files from which the defined file is 
extracted 


Definition Division 
Describes the structure of the defined file 


ENTIFICATION 


IDENTIFICATION DIVISION. rablatis 
PROGRAM-ID.data-definition-name. 
[AUTHOR.comment-entry. ] 
[INSTALLATION.comment-entry. ] 
[DATE-WRITTEN.comment-entry. ] 
[DATE-COMPILED.comment-entry. ] 
[SECURITY.comment-entry. ] 
[REMARKS .comment-entry. ] 


DATA 
DIVISION 


are! 5 


DEFINITION 
DIVISION 


DATA DIVISION. 
FILE SECTION. 
FD file-name-l.record-description 
[record-description]... 
[FD file-name-2.record-description 
[record-description]...]... 


DEFINITION DIVISION. 
defined-file-definition 





Figure 12-5. Overall Format of a Data Definition 


The identification and data divisions are similar to those in a 
COBOL program. While the definition division is unique to IMS, 
its syntax is similar to COBOL. 
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Sample data definition 1 To describe how you set up a data definition, refer to Figure 
12-6. It shows a sample data definition for the defined file 
EMPLS. 


LINC NOe SEQ, SOURCE STATEMENT 


00001 IDENTIFICATION DIVISION, 

n0c02 PROGRAM-IDe BASIC-DATA-DEF « 

focus DATA DIVISION» 

oorus FILE SECTION® 

00°uS FD EMPFILE, 

o0c06 O1 EMPLOYEE-RECe 

ooco7 02 EMPL-NAME 

pocos 02 SSNO 

poco9 C2 DEPT-NAME 

ngsin M2 ENTRY 

00711 DEFINITION DIVISION» 

o0ci2 DEFINED FILE EMPLS PASSWORD 

90013 DEFINED RECORD EMPLOYEE 

o0cl4 FROM EMPLOYEE-REC ; 
00215 ALLOW ADD AND DELETE Key is 
00c16 IOENTIFIER EMP-NM FROM EMPL-NAME f EMP-NM 
00c17 ITEM SSNO ; 
o0ci8 ITEM DEPT-NAME 





Figure 12-6. Data Definition for Defined File EMPLS 





Data definition name Note that in the identification division the data definition name is 
BASIC-DATA-DEF. 





Conventional file(s) The data division describes the conventional file from which the 
defined file is built. The conventional file name is EMPFILE. It 
contains EMPLOYEE-REC records and each record contains four 
fields - EMPL-NAME, SSNO, DEPT-NAME, and ENTRY. 





Defined file name The definition division describes the structure of the defined file 
(EMPLS). 


The defined file statement begins a defined file definition and 
names the file. The name distinguishes the defined file from other 
defined files which may exist on the named record (NAMEREC) 
file. 











UP-9205 SPERRY UNIVAC OS/3 12-9 
IMS CONCEPTS AND FACILITIES 





DATA DEFINITION 





Other uses of the You use the defined file name to refer to the defined file in a 
defined file name number of places outside the data definition: 


Keyword parameters DFILE and DDRECORD in the ACTION 
section of the configuration 


Keyword parameters FN and DDN in the password definition 
input to the NAMEREC file utility 


The defined-fileename parameter in action program function 
calls to defined record management 


> The defined-filename and data-def-rec-name fields in the 
program information block for COBOL, BAL, and RPG Il 
action programs 


The IMS system support functions user guide, UP-8364 (current 
version) describes IMS configuration and the NAMEREC file utility. 
Action programs are discussed in the current version of the IMS 
action programming in COBOL and BAL user guide, UP-9207 and 
the IMS action programming in RPG Il user guide, UP-9206. 


& Specifying a password The PASSWORD parameter allows access to the defined files. 
Passwords are used only in conjunction with UNIQUE action 

programs. 
Use with UNIQUE When you specify PASSWORD, terminal operators enter the 


defined-file-name as a password in the UNIQUE OPEN command 
to access a defined file. If you choose, you can omit PASSWORD 
Creating passwords with and define a password for use with UNIQUE by running the 
NAMEREC file utility NAMEREC file utility. This allows you to limit defined file access 
to specific UNIQUE terminals and use multiple passwords to 
access the same defined file. 


Defined record name The defined record statement names the defined record. 
Source of the The FROM clause identifies the conventional record from which 
defined record the defined record is built. In Figure 12-6 the conventional record 


is EMPLOYEE-REC. Since this is the only conventional record 
described, the FROM clause seems irrelevant. However, many 
data definitions describe several conventional files and many 
defined records. In such a case, it is important to link each 
defined record to the conventional records from which it is built. 


You write a separate defined record definition for each defined 
record type in the defined file. 


UP-9205 
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Allowing for updating 


Specifying the identifier 


Defining other fields 





The ALLOW ADD AND DELETE clause permits terminal operators 
using UNIQUE or user-written action programs to add or delete 
defined records. 


The identifier statement locates the data in the conventional file. 
The identifier is part of the record key of the conventional file 
(Figure 12-3). Because identifiers are derived from key fields, 
defined records can only be built from records in: 


indexed files; or 
p> a data base subschema. 


The item statement describes other fields in the conventional 
record which are to be included in the defined record. 


At this point, the data definition for defined record EMPLOYEE is 
complete. Figure 12-7 _ illustrates conventional records 
EMPLOYEE-REC. 


ABRAMS , MARKAAAAAAAAAA3 89314828PRODUCT 1 ONAAAAS 5189 
ACKERMAN , GWENAAAAAAAA2 2958725 9MARKET INGAAAAA2 2041 
ADAMS , BENAAAAAAAAAAAA2 4289834 4MARKET INGAAAAAS 8297 


ALLEN, JAMESAAAAAAAAAAI 974 484730FFICESERVICES15548 
ARTHUR , MON I CAAAAAAAAABE67531675L EGALAAAAAAAAAI 8861 
BAINES, CHARL E SAAAAAAA1 8963479 8ACCOUNT I NGAAAA3 2342 
BILKER, HAROLDAAAAAAAA3 4897888 5PRODUCT 1 ONAAAAS769 
BONDS, ALL ISONAAAAAAAA2Z 285611 94QUALITYCONTROL46251 
BROOKS, ELAINEAAAAAAAAI77338959DEVELOPMENTAAA2 3866 
BROOKS , JOHNAAAAAAAAAA1 2931221 OMARKET INGAAAAA27 454 





Figure 12-7. Excerpt from EMPFILE Showing Conventional 
EMPLOYEE-REC Records 
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Figure 12-8 shows the resulting EMPLOYEE defined records 


displayed at the terminal 


in 


response to a UNIQUE LIST 


command. Figure 12-9 shows how the same 10 records are 
delivered by defined record management to an action program. 


* EMP-NM 
ABRAMS , MARK 
ACKERMAN, GWEN 


ADAMS, BEN 
ALLEN, JAMES 
ARTHUR, MONICA 
BAINES, CHARLES 
BILKER, HAROLD 
BONDS ALLISON 
BROOKS, ELAINE 
BROOKS, JOHN 


SSNO 
369314828 
229587259 
2428968344 
197448473 
867531675 
189634798 
348978885 
228561194 
177338959 
129312218 





DEPT -NAME 
PRODUCTION 
MARKETING 
MARKETING 
OFFICESERVICES 
LEGAL 
ACCOUNTING 
PRODUCTION 
QUALITYCONTROL 
DEVELOPMENT 
MARKETING 


Figure 12-8. First Few EMPLOYEE Defined Records as Listed at 


a Terminal by UNIQUE 


ABRAMS , MARKAAAAAAAAAA3 89314828PRODUCT I ONAAAA 
ACKERMAN , GWENAAAAAAAA2 2958725 9MARKET INGAAAAA 
ADAMS , BE NAAAAAAAAAAAA2 42899 344MARKET INGAAAAA 


ALLEN, JAMESAAAAAAAAAA1974484730F FICESERVICES 
ARTHUR , MONI CAAAAAAAAABE67531675LEGALAAAAAAAAA 
BAINES , CHARLESAAAAAAA1 89634798ACCOUNT INGAAAA 
BILKER, HAROLDAAAAAAAA3 4897888 5PRODUCT IONAAAA 
BONDS ,ALLISONAAAAAAAA2Z 285611 94QUALITYCONTROL 
BROOKS , ELAINEAAAAAAAAL77338959DEVELOPMENTAAA 
BROOKS , JOHNAAAAAAAAAAL 2931221 OMARKET INGAAAAA 





Figure 12-9. First Few EMPLOYEE Defined Records as Delivered 


to an Action Program 


UP-9205 


DATA DEFINITION 


More complex 
conventional file 
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The data definition we've just described is a simple one. It 
creates one defined file with one type of defined record; and that 
defined record accesses one conventional file only. Now we’re 
ready to look at a slightly more involved example. Figure 12-10 
illustrates a sample data definition for defined file EMPDEPS. 


LINE NO. SEQ SOURCE STATEMENT 


001 IDENTIFICATION DIVISION. 

002 PROGRAM-ID. EMP-AND-DEP. 

003 DATA DIVISION. 

004 FILE SECTION. 

005 FD EMPFILE. 

006 01 EMPLOYEE-REC. 

007 @2 EMPL -NAME X(21). 


009 @2 DEPT-NAME X(21).: 
010 @2 ENTRY X(5). . 
011 DEPENDENT-REC. 

012 @2 EMPL-NAME X(21). 
013 @2 DEP-NAME X(21).. 


015 @2 D-SSN X(9). 
016 @2 FILLER X(12). 
017 DEFINITION DIVISION. 

018 DEFINED FILE EMPDEPS PASSWORD 

019 DEFINED RECORD DEPENDENT 

020 FROM EMPLOYEE -REC 

021 ALLOW ADD AND DELETE 

022 IDENTIFIER EMP-NM FROM EMPL -NAME 


024 ITEM DEPT-NAME 

025 SUPPLEMENT DEPENDENT- TRAILER 
026 FROM DEPENDENT-REC 

027 , POINTER IS EMP-NM 

028 ITEM DEP-NM FROM DEP-NAME 
029 ITEM D-SSN 





Figure 12-10. Data Definition for Defined File EMPDEPS 


In the identification division, the data definition name_ is 
EMP-AND-DEP. The data division describes the conventional file 
EMPFILE. In this instance EMPFILE contains not one but two 
record types, EMPLOYEE-REC and DEPENDENT-REC. For 
EMPLOYEE-REC three ffields are described; and for 
DEPENDENT-REC, four. Note that the field EMPL-NAME appears 
in both records. 
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Allowing access In the definition division, the defined file name is EMPDEPS. The 

with UNIQUE PASSWORD parameter indicates that UNIQUE users have access 
to this defined file by entering at the terminal the defined file 
name along with the OPEN command. 


Describing the The defined record DEPENDENT is built from the conventional 

defined record record EMPLOYEE-REC. It allows for addition and deletion of 
records and has two fields: EMP-NM, the identifier or mini-key for 
the defined record, and DEPT-NAME. Up to this point the 
definition division closely resembles the one illustrated in Figure 
12-6. 


Creating a supplement to Here, however, the similarity ends. We have added a supplement 

the defined record to the defined record DEPENDENT. The supplement allows you to 
add fields to the defined record, in this case DEPENDENT, by 
drawing data from another conventional record in the same file or 
in a different file. Figure 12-11 shows how this happens. 


curcnse| sono Jerr aan ENTRY EMPL-NAME | DEP-NAME | D-SSN |} FILLER 





Figure 12-11. Creating a Defined Record with Supplement 


Figure 12-11 shows how we supplement the initial defined 
record DEPENDENT by adding the fields DEP-NM and D-SSN 
drawn from the conventional record DEPENDENT-REC. Note that 
the field EMPL-NAME links the two conventional records and 
allows us to access data in both records. 
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Figures 12-12 and 12-13, respectively, show the first few © 
EMPDEPS records as listed in a UNIQUE transaction and as they 
are delivered to an action program. 


* EMP-NM DEPT -NAME 
-DEP-NM D-SSN 

. ABRAMS ,MARK PRODUCTION 

. +ABRAMS, JOAN 326898119 

. ACKERMAN, GWEN MARKETING 

. ADAMS, BEN MARKETING 


- ADAMS. BONNIE 298345429 


. -ADAMS, SARA 395806297 

. ALLEN, JAMES OFFICESERVICES 

. ARTHUR, MONICA LEGAL 

. ARTHUR. WAYNE 128862348 

. BAINES CHARLES ACCOUNTING 
-BAINES CLAUDIA 631765514 
-BAINES, JOSEPH 622118963 
-BAINES, LESLIE 489259986 

. BELKER, HAROLD PRODUCTION 





Figure 12-12. First Few DEPENDENT Records as Listed at a Terminal by UNIQUE 




















ABRAMS , MARKAAAAAAAAAAP RODUCT I ONAAAA 
ABRAMS , MARKAAAAAAAAAAABRAMS , J OANAAAAAAAAAA3 26898119 
ACKERMAN, GWENAAAAAAAAMARKET ING 

ADAMS , BENAAAAAAAAAAAAMARK ET I NGAAAAA 

ADAMS , BENAAAAAAAAAAAAADAMS , BONN | EAAAAAAAAA2 98345429 
ADAMS , BENAAAAAAAAAAAAAD AMS , SARAAAAAAAAAAAA3 95986297 
ALLEN, JAMESAAAAAAAAAAOFFICESERVICES 

ARTHUR , MONI CAAAAAAAAAL EGA LAAAAAAAAA 

ARTHUR , MON | CAAAAAAAAAAR THUR , WAYN EAAAAAAAAA 1 26862348 
BAINES , CHARLESAAAAAAAACCOUNT INGAAAA 

BAINES, CHARL ESAAAAAAABAINES , CLAUD | AAAAAAAAG 31765514 
BAINES , CHARLE SAAAAAAABAINES , JOSE PHAAAAAAAAG 22116963 
BAINES , CHARLESAAAAAAABAINES , LESL I EAAAAAAAAS 89259986 
BILKER, HAROLDAAAAAAAAP RODUCT I ONAAAA 





Figure 12-13. First Few DEPENDENT Records as Delivered to an Action Program 
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By creating a series of defined records and supplements in your 
data definition, you can achieve tremendous flexibility without 
ever altering your user files. 


Creating hierarchical If your applications should require even more sophisticated file 

defined records manipulation, the data definition also provides the capability of 
creating a defined file with a hierarchy of relationships among its 
defined records. You accomplish this by establishing parent-child 
relationships among defined records. For detailed information on 
how to set up these hierarchical relationships, consult the IMS 
data definition and UNIQUE user guide, UP-9209 (current 
version). 
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13. The IMS File Processing 
Package — UNIQUE 


13.1. A LOOK AT UNIQUE 


Definition 


Advantages 


Reference manual 


UNIQUE is a set of IMS-supplied action programs that allow you 
to access your files. With UNIQUE you can perform retrieval and 
update functions, as well as calculate statistics on your files. 


Since UNIQUE is a packaged set of programs, it has certain 
limitations. If you want to tailor IMS to your individual 
programming needs, you should write your own action programs. 
However, if you want to get online quickly and see how IMS 
operates, UNIQUE is an excellent way to do it. 


UNIQUE illustrates very well the conversational nature of IMS. For 
every UNIQUE command entered at the terminal, the operator 
receives a response from IMS. In addition, UNIQUE furnishes a 
speedy means of displaying and updating files without doing any 
programming at all. 


In this section we provide a brief overview of UNIQUE and its 
commands. For a detailed discussion of how to use UNIQUE, 
consult the IMS data definition and UNIQUE user guide, UP-9209 
(current version). 


UP-9205 
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13.2. USING UNIQUE 


File support 


Accessing a defined file 


Defining passwords 





A UNIQUE conversation is a series of commands (input) and 
responses (output) dealing with a particular defined file. 
Whenever we talk about files in conjunction with UNIQUE, we're 
talking about defined files, since you can use UNIQUE only with 
defined files. Figure 13-1 illustrates terminal operator access to 
defined files. 


FILE 
UNIQUE MANAGEMENT 


DEFINED 


RECORD 
MANAGEMENT CONVENTIONAL 


FILES 


DATA 
DEFINITION 
RECORDS 


Figure 13-1. UNIQUE Uses Defined Files 


To access a defined file with UNIQUE, you must know the 
password for that file. A password, defined in the data definition, 
is the same as the defined file name and all configured terminals 
can use it. 


Passwords can also be defined by the IMS administrator using 
the NAMEREC file utility. The administrator can restrict a 
password to specific terminals and can change passwords, even 
voiding a password defined in the data definition. The NAMEREC 
file utility is described in detail in the IMS system support 
functions user guide, UP-8364 (current version). 
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@ 13.3. UNIQUE COMMANDS 


Communicating with 
UNIQUE 





Once you know the password for a particular defined file, you 
communicate with UNIQUE through a series of commands 
entered at the terminal. These commands tell IMS what file 
activities to perform. The UNIQUE commands are 


Initiates the UNIQUE transaction and opens a dialog with a 
defined file identified by its password. 


Ends the UNIQUE transaction. 

Displays the contents of a record. 

Selects the next identifier from the most recent DISPLAY, 
DELETE, ADD, or CHANGE command and performs the same 


function. 


Displays a record, which you can then delete by entering the 
OK command. 


Complete an update function - DELETE, ADD, or CHANGE. 
Cancels an update command - DELETE, ADD, or CHANGE. 


Initiates a series of inputs and responses that result in adding a 
record to the defined file. 


Initiates a series of inputs and responses that result in changing 
a defined record. 


Lists all or selected portions of a file and performs statistical 
functions. 


Displays the next screenful of data from the previous LIST or 
DETAIL command. 


Gives a secondary listing without interrupting LIST command 
processing. 


Displays the format of records in the defined file, the most 
recent LIST and DETAIL commands, and any outstanding 
DISPLAY, DELETE, ADD, or CHANGE command. 


These commands may be changed by using the LANGUAGE section of the IMS 
configurator. Listed are the default UNIQUE lexicon commands. 


UP-9205 
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13.4. UNIQUE APPLICATION 


OPEN and CLOSE 
commands 


Command formats 


Defining terms 


Displaying a record 


Screen format 


Reference manual 


The first OPEN command you enter starts the UNIQUE 
transaction and opens a dialog with a defined file. Additional 
OPEN commands automatically close the dialog with the current 
defined file and open dialogs with other defined files. The 
UNIQUE transaction ends when you enter a CLOSE command. 


You can enter UNIQUE commands at display or hard copy 
terminals. The format for most UNIQUE commands is the same, 
regardless of the terminal you're using. Only the ADD and 
CHANGE commands have different formats. You can _ enter 
UNIQUE commands in uppercase or lower case letters; but 
UNIQUE output is always displayed in uppercase. 


When output appears at the terminal, fields in the defined record 
are displayed as column headers. The first field in the defined 
record is called the identifier. The other fields are called 
ITEM-NAMES. Let's say there is a defined file, EMPLOYE, which 
contains PERSONAL records. These records provide general 
information about each employee in company ABC. Each 
PERSONAL record has fields called EMP-NAME, ADDRESS, CITY, 
ST, ZIP, PHONE, and S-S-NO. Figures 13-2 and 13-3 show this 
correspondence. 


The OPEN command, followed by the password EMPLOYE (in 
this case, the password is the same as the defined file name), 
signals the start of the UNIQUE dialog with the EMPLOYE file. 
The operator then identifies the operation to be performed 
(DISPLAY) and the record to be displayed (BOB F. SMITH) which 
is the identifier name. You always use the identifier name (the 
first field in the record) to display or update a record. 


Figure 13-3 shows that the fields in the PERSONAL record are all 
displayed as column headers and the data about Bob F. Smith is 
filled in under those headers. Bob F. Smith is the identifer for the 
record and the other fields are item-names. 


For an in-depth discussion of the use of these and other UNIQUE 
commands, see the IMS data definition and UNIQUE user guide, 
UP-9209 (current version). 
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DISPLAY 'BOB F. 


OPEN EMPLOYE 
DISPLAY 'BOB F. SMITH’ 


EMP - NAME ADDRESS CITY ST ZIP 


BOB F. SMITH 727 ULSTER PLACE BORDEN WI 77351 
PHONE $-S-NO 


202-677-7371 242-828-8008 





Figure 13-3. Output Screen Generated by UNIQUE 
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action 
The basic unit of work in IMS. An action consists 
of an input message, the processing of that 
message by one or more action programs, and 
the output of at least one message. 


action control table 
Table that describes to IMS the action program or 
programs that process a specific action. Contains 
information on the files used in processing the 
action and the sizes of the largest input and 
output messages. 


action program 
A program that works with IMS to access, 
retrieve, add, change, or delete data from your 
files. One or more action programs perform an 
action. 


action program area, snapshot dump 
Area of snapshot dump that contains the 
executing load module as it existed in main 
storage when the program terminated. 


action program routing 

In distributed data processing, one way that IMS 
can route a transaction to a remote system. The 
terminal operator enters a transaction code that 
initiates a transaction at the local {MS system. 
The COBOL or basic assembly language (BAL) 
action program processing this transaction issues 
an ACTIVATE function call to IMS, which creates 
a message that initiates another IMS transaction 
at the remote site. The remote IMS processes the 
transaction and sends a message back to the 
originating action program or its successor 
program. 





Glossary 1 





Glossary 


action scheduling 
A component of applications management that 
schedules an action for each input message by 
allocating main storage and other resources 
needed by that action. Also handles termination 
of action programs. 


ACTION section, configurator 
Section of configurator input that describes the 
actions used in the configuration. 


activation record 

A main storage interface area that contains and 
passes control information and data between the 
action program and IMS. Can contain the 
continuity data area (CDA), defined record area 
(DRA), input message area (IMA), output message 
area (OMA), program information block (PIB), and 
work area (WA). 


activation record area, snapshot dump 
Area of snapshot dump that shows the contents 
of the activation record when the program 
terminated. 


ADD command, UNIQUE 
UNIQUE command that initiates a series of inputs 
and responses that change a defined record. 


after-image 
The image of a record after updating occurs. 


applications management 
A major component of IMS that controls the 
execution of action programs. Includes action 
scheduling and file management. 


assembly, step in IMSCONF 
Step in IMSCONF jproc that takes the configurator 
output, plus information in your data files, and 
converts it into machine-readable code. 
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AUDCONF (audit and continuity data file) 
IMS internal file that is the  single-thread 
counterpart of the AUDFILE and CONDATA files 
for multithread IMS. 


AUDFILE {audit file) 
IMS internal file that handles online recovery and 
contains IMS control information recorded when a 
transaction terminates. 


automatic status messages 
Messages automatically generated by multithread 
IMS to notify the terminal operator of the status 
of the last input message. 


backward recovery 
A type of offline recovery that uses 
before-images recorded on the trace file to 
restore data files to their original state or to the 
state they were in at a specified date and time. 


BATCH parameter, configuration 
Parameter that enables you to designate batch 
processing modules in your configuration. 


batch processing 
A method of processing groups of transactions in 
card format instead of through a display terminal. 
You can process batch transactions online or 
offline without an active terminal network. 


batch processor 
An optional component of IMS that enables you 
to enter input for IMS transactions on cards 
instead of interactively and to direct output to a 
printer or printer file. 


batch transaction 
A transaction entered in card format instead of 
interactively. 


before-image 
The image of a record before any updating 
occurs. 


Cc 


CALL function (function call) 

A request to IMS for input/output or other 
services. In COBOL action programs, a CALL 
function is in the form of a CALL statement. In 
BAL action programs, a CALL function is in the 
form of a CALL or ZG#CALL macroinstruction. 
RPG Ii action programs do not use CALL 
functions, but the compiler converts normal RPG II 
file requests into function calls. 


CANCEL command, UNIQUE 
UNIQUE command that cancels an _ update 
(DELETE, ADD, or CHANGE) command. 


CCA linkage, step in IMSCONF 
Step in IMSCONF jproc that links the 
communications control area object module to the 
configurator modules to create the IMS 
configurator program. 


CHTBL, IMS transaction code 
Transaction code that lets you make temporary 
changes to the internal tables generated by your 
entries in the ACTION and PROGRAM sections of 
the configurator. 


CLOSE command, UNIQUE 
UNIQUE command that ends a UNIQUE 
transaction. 


COMMCT 
Phase of system generation that generates the 
communications network and an ICAM load 
module that supports online IMS. 


communications adapter 
Hardware device that controls and coordinates 
the message flow between ICAM and_ the 
terminals. 


CONDATA (continuity data file) 
IMS internal file required for multithread IMS when 
you use UNIQUE, when your action programs 
pass data using the continuity data area, or when 
you use the terminal output message file. 


configuration 
The process where the IMSCONF jproc executes 
the configurator program, analyzes and processes 
input to the configurator, and generates records 
for the named record file. 
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configurator 
Component of pre-online processing that, through 
the job control procedure IMSCONF, enables you 
to create an online IMS that performs the 
functions you want. 


configurator tables 
Tables created by the configurator and stored on 
the named record (NAMEREC) file. These tables 
are the transaction code table, action control 
table, and program control table. 


continuity data area (CDA) 
Area in the activation record that holds data an 
action program wants to save and pass to the 
action program that follows it. 


continuous output 
An output message transmitted in a continuous 
series of sections without intervening input 
messages. The continuous output message must 
be the last message transmitted by the action 
program. 


D 


data definition 
A description of an IMS defined file. 


data definition processor 
An IMS _ utility program that creates a data 
definition record in the named record file and 
produces a printed description of the defined file 
and a diagnostic listing. 


data division, data definition 
Section of a data definition that describes the 
conventional files from which the IMS defined file 
is extracted. 


data management, OS/3 
The interface between IMS file management and 
your data files. 


data manipulation language (DML) 
A special data base access language that 
resembles COBOL and is used in action programs 
to communicate with the data base management 
system (DMS). 





dedicated network, ICAM 
A communications network in which all lines and 
terminals are dedicated to IMS for the length of 
the session. 


defined file 
A logical file that IMS builds from records in your 
existing data files. 


defined record 
A record that redefines records in your existing 
files. 


defined record area (DRA) 
Area in the activation record used by defined 
record management when action programs use 
defined records. 


defined record management 
The IMS component that handles requests from 
UNIQUE and action programs for defined records. 


definition division, data definition 
Section of a data definition that describes the 
structure of the defined file. 


delayed internal succession 
Termination type in which one action program 
processes an input message and then queues an 
input message to a successor action program 
without sending that message to the terminal. 


DELETE command, UNIQUE 
UNIQUE command that displays a record, which 


you can then delete by entering the OK 
command. 


delivery code 
ICAM's response to a continuous output message 
informing IMS whether or not the message was 
successfully delivered to the terminal or printer. 


DETAIL command, UNIQUE 
UNIQUE command that gives a secondary listing 
without interrupting LIST command processing. 


detailed status code 
A two-byte field in the program information block 
that contains specific information about why a 
function call was unsuccessful. Supplements the 
status code by giving more detailed information. 
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device media control language (DMCL) 
Language that describes the physical structure of 
a data base, identifying the location of the data in 
the data base. 


dialog transaction 
A transaction that consists of a sequence of two 
or more actions. 


directory routing 

In distributed data processing, one way that IMS 
can route a transaction to a remote system. The 
terminal operator enters a transaction code that 
identifies a transaction for processing at a 
particular remote site. IMS sends the transaction 
code to the remote IMS, which processes the 
transaction and sends a message back to the 
terminal operator. 


disk buffer file 
A file that holds holds input messages for ICAM 
to reduce the amount of main storage taken up 
by network buffers. 


DISPLAY command, UNIQUE 
UNIQUE command that displays the contents of a 
record. 


distributed data processing 
System that allows two independent computer 
systems to communicate with one another. They 
are linked together through telecommunications 
so that each can use the other's capabilities and 
data. 


DITBL, IMS transaction code 
Transaction code that displays the contents of 
the fields in your action and program configurator 
tables. 


DLMSG, !MS transaction code 
Transaction code that displays the last effective 
output message sent to your terminal from an 
action program or UNIQUE. 


DLOAD, IMS transaction code 
Transaction code that loads a user-written UTS 
program from the IMS toad library downline to a 
UTS 40 or UTS terminal. 


DRCRDMGT section, configurator 
Section of configurator input that defines the level 
at which you intend to use defined record 
management. 


dynamic terminals 
Terminals that are attached to IMS only while you 
are using them. 


edit table generator 
An offline IMS utility that uses edit tables to 
convert freeform input entered by terminal 
operators into fixed formats required by the 
action program. IMS uses these edit tables to 
check the input for data type, value ranges, and 
presence of required fields. 


external succession 
Termination type in which both the first and the 
successor action programs process an_ input 
message and produce an output message. 


file management 
A component of applications management that 
provides all action program 1/O functions and 
provides access to your data files through OS/3 
data management. It interfaces with IMS internal 
files and your data files. 


FILE section, configurator 
Section of configurator input that describes each 
user data file to be accessed by IMS. 


forward recovery 
A type of offline recovery that uses after-images 
recorded on the trace file for recovery purposes 
when a portion of your data files is destroyed. 


function key 
A terminal key that can be used as a transaction 
code when your terminal is not processing a 
transaction or as a response to an output 
message when you are using external succession. 


G 


GENERAL section, configurator 
Section of configurator input that describes 
general characteristics of the online IMS system. 
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global network, ICAM 
A communications network that supports IMS 
and other communications programs at the same 
time. 


headers section, snapshot dump 
Area of snapshot dump that gives general 
information about which program was _ running 
when the snapshot dump occurred and what 
caused it. 


identification division 
Section of a data definition which assigns a 
unique name to the data definition. 


identifier 
A portion of the record key of the conventional 
record from which the defined record is created. 
It is used to locate the data in your conventional 
files. 


immediate internal succession 
Termination type in which one action program 
processes the message and schedules another 
program to continue the processing. When the 
second program finishes processing, the program 
generates an output message and terminates. 


IMSCONF job control procedure 
An _ |IMS-supplied job control procedure that 
generates and executes an IMS_ configurator 
program creating an online IMS. 


information management system (IMS) 
An interactive transaction processing system that 
enables you to easily access and modify your 
data files. 


initialization, step in IMSCONF 


Step in IMSCONF jproc that allocates and 
initializes IMS internal files. 


input message area (IMA) 
Area in the activation record that receives input 
from the terminal. 





integrated communications access method (ICAM) 
Communications software that handles all input 
and output between your terminals and IMS. 


internal message control 
An IMS component that processes input and 
output messages, executes terminal commands, 
and controls message editing. 


INVOKE statement, in COBOL/DML action programs 
A statement that identifies the schema, 
subschema, and device media control language 
modules describing the physical and_ logical 
structure of a data base. 


LANGUAGE section ,configurator 
Section of configurator input that creates a 
UNIQUE lexicon record in the named record file. 
This lexicon record redefines UNIQUE commands. 


LDPFILE (fast loader file) 
IMS internal file required when you _ specify 
FASTLOAD=YES. The first time they are called 
by a transaction, action programs are copied into 
the LDPFILE from the action program load library 
(LOAD). After that, the action programs are 
loaded from the LDPFILE. 


library, IMS 
A collection of source, object, and load modules 
that are part of your IMS software. 


line disconnect 
A feature that allows an action program to 
disconnect a single-station dial-in line, enabling 
another terminal to use the same dial-in line. 


LIST command, UNIQUE 
UNIQUE command that lists all or selected 
portions of a file and performs _ statistical 
functions. 


LOCAP section, configurator 
Section of configurator input that defines a local 
application program to a remote computer 
system. 
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lock-for-transaction 
Record locking capability that locks records until 
the end of an action and audits updates. A 
before-image is written to the audit file and, if the 
transaction terminates abnormally, the original 
image of the record is restored. 


lock-for-update 
Record locking capability that locks records only 
for the duration of the update. Updates are not 
audited and are not rolled back if the transaction 
terminates normally. 


M 


master terminal commands 
Commands that control and monitor the entire 
IMS network. You can enter these commands 
only from the master terminal or, when 
designated, the system console or master 
workstation. 


MORE command, UNIQUE 
UNIQUE command that displays the next screenful 
of data from the previous LIST or DETAIL 
command. 


multiple messages 
Type of action program output where the 
program produces more than one output message 
when the output is greater than screen capacity. 


multithread processing 
The processing of actions concurrently for 
different transactions. 


NAMEREC file (named record file) 
An internal IMS file that contains all the tables 
and records needed by online IMS. These tables 
include configuration tables, data definition 
records, edit tables, and password definition 
tables. 


NAMEREC utility 
Component of pre-online processing that initializes 
the named record (NAMEREC) file. 
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network definition macroinstructions 
A set of macroinstructions that define the type of 
ICAM support required, the network of lines and 
terminals, and the input/output requirements. 


NETWORK section, configurator 
Section of configurator input that defines the 
ICAM network to support your online IMS and 
provides additional information about your IMS 
system. 


NEXT command, UNIQUE 
UNIQUE command that selects the next identifier 
from the most recent DISPLAY, DELETE, ADD, or 
CHANGE command and performs the same 
function. 


normal termination 
Termination type that tells IMS that processing is 
complete after a single action program or a series 
of action programs have finished executing. 


O 


offline processing 
Processing that consists of operations that 
recover damaged or inconsistent files. The two 
recovery programs’ available with offline 
processing are the offline recovery utility and the 
tape copy program. 


offline recovery 
Type of recovery that restores damaged or 
inaccurate files after online processing has 
terminated. 


offline recovery utility 
Program that reconstructs your files when online 
recovery fails or cannot correct the problem. 


OK command, UNIQUE 


UNIQUE command that completes an update 
function - DELETE, ADD, or CHANGE. 


online module linkage, step in IMSCONF 
Step in IMSCONF jproc that takes the output of 
the configurator and assembly operations, links it 
with IMS library modules into an executable IMS 
load module, and stores it in a load library. 
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online processing 
Processing that is transparent and_ functions 
internally to enable you to process transactions. 
The five components of online processing are 
start-up modules, applications management, 
internal message control, shutdown modules, and 
action programs. 


online recovery 
Type of recovery that restores damaged or 
inaccurate files during online processing. 


OPEN command, UNIQUE 
UNIQUE command that initiates a UNIQUE 
transaction and opens a dialog with a defined file 
identified by its password. 


operator routing 

In distributed data processing, one way that IMS 
can route a transaction to a remote system. The 
terminal operator prefixes the transaction code 
with a special character that identifies the 
transaction for remote processing. The remote 
IMS processes the transaction and sends a 
message back to the terminal operator. 


OPTIONS section, configurator 
Section of configurator input that defines optional 
IMS features to be included in the configuration. 


output-for-input queueing 
Output message that starts an IMS transaction at 
another terminal. 


output message area (OMA) 
Area that holds the output message that the 
action program generates. 


PASSWORD parameter, in data definition 
Parameter that protects defined files by limiting 
access to them. 


password 
A name associated with a particular IMS defined 
file or subfile for data security purposes. 


pre-online processing 
Processing that prepares and configures IMS to 
define your online IMS environment. 


program contro! table 
Table that tells IMS about the specific program or 
programs processing an action. It contains data 
about whether the program is serially reusable, 
shared, or reentrant, and whether or not the 
program permanently resides in main storage. 


program information block 
Area in the activation record that passes control 
information between IMS and the action program 
during program processing. 


PROGRAM section, configurator 
Section of configurator input that describes the 
action programs to be included in the IMS 
configuration. 


Q 


quick recovery 
A type of = offline recovery that uses 
before-images recorded on the trace file to roll 
back transactions when there is a system failure 
or an emergency IMS termination. 


random function calls 
Call from an action program that alerts IMS file 
management to handle a random access file 
request. Random function calls are GET, GETUP, 
PUT, INSERT, and DELETE. 


recovery 
A method of protecting your data files so that, if 
something goes wrong during updates, your files 
can be restored. 


reentrant code 
A type of coding that enables an action program 
to be used concurrently by two or more users. 
Programs written in reentrant code are completely 
shareable. Because more than one action program 
is using the program, no parts of the program can 
change during action programming. 


register section, snapshot dump 
Area of snapshot dump that contains both IMS 
and action program registers or just IMS 
registers, depending on what caused the dump. 
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RESGEN, phase of system generation 
Phase of system generation that allows you to 
generate your own system resident (SYSRES) 
disk pack. 


resident ICAM 
An ICAM load module that remains in main 
storage at all times. 


roliback 
The process of restoring the original image of a 
record when a transaction terminates abnormally. 


schema 
The global view of a data base's logical structure. 
It is a total picture of the physical and_ logical 
structure of the data base. 


screen format services 
A separate software package that allows users to 
create formatted screens. IMS interfaces with 
screen format services to allow action programs 
to use screen formats for input and output 
messages. 


serially reusable code 
A type of coding that allows only one user at a 
time to access the action program. Another 
terminal requesting the same program must wait 
until the first user is finished. 


sequential function calls 
Call from an action program that alerts IMS 
management to handle a sequential access file 
request. Sequential function calls fro random files 
are SETL, SETK, GET, and ESETL. Sequential 
functions for sequential files are GET and PUT. 


shared code 
A type of coding that enables an action program 
to be used concurrently by two or more users. 
Programs written in shared code are only partially 
shareable, and only COBOL action programs can 
use shared code. 


SHOW command, UNIQUE 
UNIQUE command that displays the format of 
records in the defined file, the most recent LIST 
and DETAIL commands, and any outstanding 
DISPLAY, DELETE, ADD, or CHANGE command. 


Glossary 8 
shutdown, IMS 
The process of ending an IMS session. 
simple transaction ° 


A transaction that consists of a single action. 


single message output 
A type of output in which an action program 
produces only one output message, which is sent 
to the terminal when the program finishes 
processing. 


single-thread processing 
The processing of one action at a time. 


snapshot dump 
A picture of what goes on internally when your 
action program is processing. The snapshot dump 
shows the program itself, the areas of the 
activation record used by the action program, and 
what, went wrong with the program. 


standard terminal commands 
Commands that help you control message 
transmission and terminal operations and testing. 
They can be entered from any terminal and, if 
console support is configured, from the console 
or master workstation. 


start-up, IMS 
The process of bringing IMS online. 


STATFIL (statistical data file) 
IMS internal file that contains statistical data 
recorded during online processing. 


static terminals 
Terminals that are attached to IMS for the entire 
session. 


status code 
A two-byte field in the program information block 
that defines whether or not a function call was 
successfully carried out and if not, why. 


subschema 
A logical view of a segment of the data base. It 
is a portion of the schema useable by a specific 
application. 


successor program 
An action program that follows another action 
program and resumes processing of a transaction. 
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supervisor 
A program that controls the activity of other 
programs operating within the system. 


SUPGEN, phase of system generation 
Phase of system generation in which you specify 
the number of communication lines, priority levels 
for IMS tasks, number of job slots required, file 
locking capabilities, and DTF, CDM, or mixed data 
management mode. 


switched message 
A message sent to a terminal as a result of an 
input message from another terminal. 


SWTCH, IMS transaction code 
Transaction code that sends a message to 
another terminal or terminals, including the 
system console. 


system generation (SYSGEN) 
Phase in online generation process which creates 
a supervisor that supports IMS. The three phases 
of SYSGEN are SUPGEN, RESGEN, and COMMCT. 


tape copy program 
Program that recovers a tape trace file that is left 
open as the result of a system failure. This 
program then produces a new trace file that you 
can use for offline recovery. 


terminal 
Any point in a system or communications 
network where data can enter or leave. 


terminal control table, snapshot dump 
Area of snapshot dump that contains data related 
to the terminal that initiated the action program. 


TERMINAL section, configurator 
Section of configurator input that further defines 
the terminals already included in your 
communications network definition. 


test mode, terminal state 
Mode in which-your terminal simulates transaction 
processing but no physical alteration of your data 
files occurs. 





thread control block, snapshot dump 
Area of snapshot dump that contains data used 
to control the IMS environment. 


TIMEOUTS section, configurator 
Section of configurator input that defines the 
various time-out values. 


TOMEFILE (terminal output message file) 
An internal IMS file on which IMS writes the 
output message generated for each terminal at 
rollback points and at transaction termination, 
retaining only one message per terminal in the 
file. 


TRANSACT section, configurator 
Section of configurator input that supplies 
transaction code information to the configurator. 


transaction 


One action or a sequence of actions that 
complete a desired function. 


transaction codes 
1- to 8-character messages that identify to IMS 
the first action program in a transaction. 


transaction code table 
Table that lists all the transaction codes the IMS 
configuration supports. It also provides IMS with 
the name of the first program that processes the 
transaction. 


transaction facility, IMS 


Capability to process IMS transactions at a 
remote computer. 


transaction structures 
The two types of transactions, simple and dialog. 


transient ICAM 
An ICAM toad module that occupies main storage 
only when required, thereby freeing up main 
storage for other programs. 


TRCFILE (trace file) 
An internal IMS file used with offline recovery to 
recover data files when IMS is not online. 
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U working-storage section, COBOL/DML action 
program 
Section of a COBOL/DML action program in which 
. : : a data base management communications area 
uniform inquiry update element (UNIQUE) ‘i (DMCA) is set up for the exchange of vital 
A set of IMS-supplied action programs tr at information between IMS and DMS. 
perform a variety of retrieval and updating 


functions for defined files. 


UTS downline load feature 
Using an action program to load other programs 
from an IMS library into UTS 40 or 400 terminal 
main storage. ZSTAT, IMS transaction code 
Transaction code that generates statistics about 
your files, programs, transactions, and terminals. 


Ww 


work area (WA) 
Area in the activation record used by COBOL and 
basic assembly language (BAL) action programs 
to hold logical records during file processing and 
as a working storage area. 
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Abnormal termination, snapshot dump 
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contro! table 


program, COBOL/DML 


program area, snapshot dump 


program routing 


programs 

abnormal termination 
COBOL/DML 

coding 

complex transaction 


creating transaction structure 


definition 


design 

features 

file processing 
functions at termination 
IMS-supplied 


input message handling 
loading 
online processing 


output message generation 


processing 


program information block (PIB) 


routing 


Reference 
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8-17 


3-11 
10-2 
8-19 
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Term 


sample transaction 
scheduling 

snapshot dump area 
successor program processing 
successor-id field, PIB 
termination 


transaction 
UNIQUE 
user-supplied 


Action scheduling, applications 
management 


ACTION section, configurator 


Activation record 
contents 
definition 
function 
set up 
snapshot dump 


ADD command, UNIQUE 


Additional IMS_ features 
continuous output 
edit table generator 
initiating OS/3 job 
line disconnect 
output-for-input queueing 
screen format services 
snapshot dump 
UTS downline load 


after-images, offline recovery 
Allocating internal files 


ALTER parameter, IMSCONF 
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3.12 3-20 
3.12 3-20 
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3.1 3-1 
16 1-14 
1.6 1-12 
4.13 4-17 
3.5 3-5 
2.3 2-5 
3.4 3-4 
3.6 3-6 
8.4 8-19 
13.3 13-3 
8.1 8-2 
8.7 8-27 
8.8 8-30 
8.3 8-15 
8.2 8-10 
8.6 8-22 
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Term Reference 
Applications, UNIQUE 13.4 
Applications management, online 

processing 1.6 
Assembler source module (IMS$ASM) 4.41 
Assembly, IMSCONF 4.11 
Assigns alternate terminal command 

(ZZALT) 6.4 
AUDCONF internal file 78 
AUDFILE internal file 78 
Automatic status message 6.5 

B 

Backward recovery, offline 7.11 


Basic assembly language (BAL) 


interface, file management 7.1 
programming language 12 
Batch processing environment IL 


Batch transactions 


environment 11.1 
error messages 11.4 
file recovery 114 
processing control 11.3 
Processing preparation 11.2 
using UNIQUE lll 
before-images 
offline recovery 7.10 
online recovery 7.10 
Begin IMS session 5.1 
BILLI processing 3.14 
BILL2 processing : 3.14 
BUFFER macroinstruction 46 
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Term 


Cc 


CALL BUILD, screen format services 
feature 


CALL REBUILD, screen format services 
feature 


CALL RETURN function 
CALL SEND function 
CANCEL command, UNIQUE 


Cancel transaction command (ZZCNC) 


CCA macroinstruction 


CHANGE command, UNIQUE 
Changes master terminal command (ZZMCH) 
CHTBL transaction code 
CLOSE command, UNIQUE 
Closes data file command (ZZCLS) 
CMD parameter, IMSCONF 
CNFICS parameter, IMSCONF 
COBOL 
DML action program requirements 
interface, file management 
programming language 
Coding, action program 
Commands 
master terminal 


Standard terminal 


UNIQUE 


COMMCT system generation 
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Conventional file/record 12.1 12.1 
: : . DDPBUF parameter 9.2 9-4 
Creating transaction structure, action 
program 3.12 3-23 DDPSESS parameter 9.2 9-4 


Dedicated network, ICAM 45 4-7 
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Term 


Defined files 
accessing 
action program access 
conventional file comparison 
creation 
description 


example 
support 
UNIQUE 


Defined record area (DRA) 


Defined record management 
defined file access 
defined record access 
file management component 
IMS/DMS._ interface 

Defined records 
accessing 
data base acess 
description 
statements 

Definition division, data definition 


Delayed internal succession 


DELETE command, UNIQUE 
DEPART statement 

Designing an action program 
DETAIL command, UNIQUE 


Detailed status code, PIB 


Device media control language (DMCL) 


Dialog Transaction 


Directory routing 


Reference 


10.2 


12.4 
10.4 
12.3 
12.6 
12.6 


3.10 
3.14 


13.3 
10.2 
3.3 

13.3 


75 
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12-5 
75 
12-1 
12-2 
1-10 
1-13 
12-3 
12-1 
7-1 
12-6 
12-13 
13-2 


3-5 
12-5 


7-5 

12-5 
1-13 
10-3 


Term 


DISCFILE macroinstruction 
DISPLAY command, UNIQUE 
Displays terminal status command (ZZTCT) 
Distributed data processing (DDP) 
configuring transaction facility 
processing remote transactions at 
terminal 
programming 
transaction routing types 


DITBL transaction code 


DLMSG transaction code 


DLOAD code 
transaction 
UTS downline load 
Down terminal mark up command (ZZUP) 
Downline load, UTS 400 
DRCRDMGT section, configurator 


Dynamic terminals 


Reference 


46 


13.3 


9.2 


9.4 


9.1 


6.4 


6.4 


11.4 


6.4 
8.5 


5.1 
6.1 








“  @ 


4-8 
13-3 


6-9 
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@ Term 


Edit table generator 
action program feature 
description 
‘library module 
utility (ZH#EDT) 


End IMS session 


Environment 
batch processing 
communications 


computer 

IMS types 

message processing 
multithread 
single-thread 


Error messages 


@ External succession 


Reference 
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Term 


Facility, transaction 


File 
closing 
conventional 
IMS access 
management 


opening 
parameter 


processing, action program 


recovery 

status requests 
types 

UNIQUE updating 


File recovery 
offline recovery 
online recovery 
options 


Files, data 


Files, IMS internal 


Forward recovery, offline 


Function call 
output message 
program language 
random 
results 
sequential 


support 


Function keys, terminal 


Index 5 


Reference 


7.10 
7.10 
Table 7-4 


16 
16 
78 
79 


7.11 


Page 


ow A 
> 
~ 


Nm 


i 1 i 
_ 


' 
“SOO DS eS NSN Se 


St Ed ed as Se, 





UP-9205 SPERRY UNIVAC OS/3 Index 6 
IMS CONCEPTS AND FACILITIES 





Term Reference Page Term Reference Page 
G Identification division, data 12.6 12-8 
GAWAKE, CCA operand 6.1 6-2 Identifier, defined record 12.3 12-4 
GENERAL section, configuration 4.13 4-17 Immediate internal succession 3.10 3-18 
3.14 - 
Generating IMS 
IMS requirements 1.8 1-16 IMPART statement 10.2 10-3 
online Section 4 
system requirements 1.8 1-16 IMS access to DMS 
COBOL/DML action programs 10.2 10-2 
Global network, ICAM 45 4-7 communicating with data base 10.1 10-2 
51 5-1 configuration 10.5 10-5 
data definition 10.3 10-4 
Global user service task (GUST) 51 5-1 preprocessing 10.4 10-4 
IMS/DMS._ interface 10.1 10-1 
IMS READY message 5.1 5-2 
6.2 6-2 
6.3 6-3 
6.5 6-20 


IMS sessions 








begin 5.1 5-1 
H end 5.2 5-3 
HANGUP program, line disconnect feature 8.3 8-15 IMS supplied action programs 1.6 1-14 
3.4 3-4 
Headers, snapshot dump 8.4 8-19 
IMSCONF job control procedure 
allocating internal files 79 7-10 
contents 4 4-13 
format 4.12 4-14 
function 15 1-9 
INIT parameter 49 4-11 
initializing internal files 79 7-10 
keyword parameters 4.12 4-14 
| IMSFIL parameter, IMSCONF 4.42 4-16 
" : Indexed file 
ICAM (integrated communications access method) defined record building 12.6 12-10 
activation record 2.3 2-5 description 71 7-1 
communications adapter (CA) 2.3 2-2 72 7-3 
creation 4.6 4-8 random function call access 7.2 7-4 
definition 2.2 2-2 
environment 4.6 4-8 Information management 11 1-1 
internal operation 2.3 2-3 
HOE UME. 2.3 2-3 INIT parameter, IMSCONF 49 4-11 
load module (resident/transient) 45 4-7 412 4-16 
NAMEREC 2.3 2-5 
network buffer 2.3 2-3 Initialization step, IMSCONF 4.11 4-13 
network types (dedicated/global) 45 4-7 
blest module 46 4-9 initializing internal files 79 7-10 
queue 6-5 6-16 
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@ Term Reference Page Term Reference Page 
Initiates online batch processing (ZZBTH) 6.4 6-8 L 
11.2 11-5 
LANGUAGE section, configurator 4.13 4-17 
Input 
Action program message handling 3.12 3-21 LDPFILE internal file 78 7-10 
configurator 4.13 4-17 
staging buffer 3.8 3-10 Library, IMS 4? 4-2 
terminal messages 6.2 6-2 
6.4 6-6 Library module, pre-online Fig. 4-1 4-3 
Input message area (IMA) : a LIBS, LIBO, LIBL parameters, IMSCONF 4.12 4-16 
Line buffer, ICAM 2.3 2-3 
INPUT parameter, IMSCONF 4.12 4-16 
Line disconnect feature 8.3 8-15 
Interface, IMS/DMS 10.1 10-1 
LINE macroinstruction 4.6 4-8 
Internal files 
allocating 13 7-10 Linker source module (IMS$LNK) 4.11 4-13 
description 1.6 1-13 
IMS 16 1-13 LIST command, UNIQUE Fig.12-8 12-11 
18 1-9 13.3 13-3 
initializing 79 7-10 
Load module 
© Internal message control, online contents Fig. 1-9 1-12 
processing 16 i execution 5.1 5-2 
resident 45 4-7 
INVOKE statement, COBOL/DML action transient 45 4-7 
programs 10.2 10-2 
Loading action program 3.12 3-20 
Loading ICAM 5.1 5-1 
LOADM parameter 4.12 4-16 
J 5.1 5-2 
ii Heacsachon ode 6.4 6-13 LOCAP section, configuration 4.13 4-17 
9.2 9-4 
Job control procedure, IMSCONF 4.12 4-14 LOCK parameter 17 1-8 
Lock-for-transaction 77 7-8 
Lock-for-update 7] 7-8 
Locking records 77 7-8 
K LST parameter, IMSCONF 4.12 4-16 
Keyword parameters, IMSCONF 4.12 4-16 
Fig. 4-3 4-15 
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Term Reference Page Term Reference Page 
M 
Marks down malfunctioning terminal command NAMEREC file 
(ZZDWN) 6.4 6-8 action program processing 3.8 3-10 
data definition creation 48 4-11 
Marks up downed terminal command (ZZUP) 6.4 6-9 12.2 12-2 
defined file definition 12.4 12-5 
Master terminal commands 6.2 6-2 12.6 12-9 
6.4 6-8 function 2.3 2-5 
9.4 9-8 IMS interval file 1.6 1-13 
78 7-9 
Master workstation use 6.8 6-22 online IMS generation 18 1-16 
online processing 43 4-4 
mcpname parameter, COMMCT 5.1 5-1 password definition 13.2 13-2 
pre-online processing 15 1-8 
MENU processing, program 3.14 3-27 2.3 2-5 
42 4-3 
Menu selection processing 3.14 3-29 47 4-10 
set up 49 4-11 
Message control parameters 46 4-8 
NAMEREC utility (ZP#NRU) 
Message processing environment 6.2 6-2 function 15 1-8 
IMS library program 42 4-3 
MESSAGE WAITING key 6.5 6-19 requirements 49 4-11 
use 47 4-10 
MESSAGE WAITING light 6.5 6-17 
Network, communications 2.2 2-2 
Messages 41 4-2 
communications (ICAM) 2.3 2-2 45 4-7 
handling output 6.5 6-18 46 4-8 
IMS 6.5 6-20 
input 2.2 2-2 Network buffer, ICAM 2.3 2-3 
multiple 6.5 6-16 
output 6.5 6-15 Network definition macroinstructions 46 4-8 
processing environment 6.3 6-3 
single output 6.5 6-15 NETWORK section, configurator 4.13 4-17 
special feature output 6.5 6-19 
types, input/output 6.2 6-2 NEXT command, UNIQUE 13.3 13-3 
transaction codes 1.2 1-2 
Normal mode, terminal 6.3 6-4 
Modules, online processing 
shutdown 16 - Normal termination 3.10 3-15 
start-up 1.6 - 
MORE command, UNIQUE 13.3 13-3 
Multiple message output, terminal 6.5 6-16 
Multithread processing 1.3 1-5 
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@: Reference Page Term Reference Page 
O Output 
configurator Fig. 1-5 1-9 
Offline processing continuous 8.1 8-2 
batch environment 11.2 11-5 message generation 3.12 3-22 
components 17 1-14 terminal message 6.2 6-3 
description 1.4 1-8 6.5 6-15 
recovery 7.10 7-12 
711 7-13 Output message area (OMA) 2.3 2-5 
3.5 3-5 
Offline recovery ; : 
after-images 7.10 7-12 Output-for-input queueing feature 8.2 8-10 
backward 7.11 7-13 
before-images 7.10 7-12 
definition 17 1-14 
forward 7.11 7-13 
program execution 7.12 7-14 
quick 711 7-13 
OK command, UNIQUE 13.3 13-3 
Online IMS generation 
IMS requirements 18 1-1 
system requirements 1.8 1-16 
@ vive module linkage, IMSCONF 4.il 4-13 
Online processing 
action program 1.6 1-11 
batch environment, IMS 11.2 11-5 
components 1.6 1-11 
definition 1.4 1-8 
generation, IMS 1.8 1-16 
preparation 43 4-4 
writing data definitions 43 4-4 
Online recovery 7.10 7-11 
OPEN command, UNIQUE 13.3 13-3 
Opens data file command (ZZOPN) 6.4 6-9 
Operator routing 9.1 9-3 
9.4 9-7 
OPTIONS section, configuration 4.13 4-17 
0S/3 data management 2.3 2-6 
3.4 3-4 
7.1 7-1 
OS/3 job, initiating feature 8.8 8-30 
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Term 


PARAM statements 
batch processing 
startup 


PASSWORD parameter 


Passwords, pre-online processing 


Places terminal in test mode (ZZTMD) 


Pre-online processing 


Preprocessing, DML statements 
Processing menu selection 
Processing remote transactions 
Processing successor program 
Processing time frames 

Program control table 

Program execution, offline recovery 


Program information block (PIB) 


Program MENU processing 
PROGRAM section, configuration 
Programming for DDP 
Programming languages 


BAL (basic assembly language) 
COBOL 


RPG Il (report program generator) 
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Reference Page Term 


Quick recovery, offline 
11.2 11-4 
5.12 5-2 
4.10 4-12 
12.6 12-9 
43 4-4 
4.10 4-12 R 
6.4 6-7 Random access 
9.4 9-8 
11.1 11-3 Random function calls 
1.4 1-8 RCHAR parameter 
15 1-8 
4.2 4-3 Record, conventional 
43 4-4 
47 4-10 Record file utility (ZP##NRU) 
10.4 10-4 Record locking 
3.14 3-29 Recovery, file 
9.4 9-7 Recovery utility, offline 
3.13 3-24 Reentrant code, action program 
1.4 1-8 Register section, snapshot dump 
3.8 3-12 Regular and continuous output comparison 
7.12 7-14 Relative files 
description 
2.3 2-5 
3.5 3-5 random function call access 
3.11 3-18 
75 7-6 Releases ZZHLD on output (ZZRDY) 
3.14 3-27 
Remote transaction 
4.13 4-17 initiating from action program 
processing at secondary IMS 
9.3 9-4 processing at terminal 
Replaces action program in load file (ZZPCH) 
12 1-4 
12 1-4 Resends last output message (ZZRSD) 
12 1-4 


RESGEN, system generation 


Resident load module 


Index 10 
Reference Page 
7.11 7-13 
7.1 7-3 
7.2 7-4 
9.2 9-4 
12.1 12-1 
4.10 4-12 
77 7-8 


See file recovery. 


17 
3.7 
8.4 
8.1 
7.1 
7.2 
7.2 


6.4 
9.4 


9.3 
9.3 
9.4 
6.4 


6.4 
9.4 


4] 


45 


1-14 


3-8 
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Term 


Restores terminal to normal command (ZZNRM) 


RETURN function 
Rollback 

Routing, transaction 
RPG II 


programming language 
interface, file management 


Scheduling action program 

Schema module, INVOKE statement 
Screen bypass device, UTS 400 
Screen format services feature 


Secondary IMS, remote transaction 
processing 


SEND function 
Sequential 
access 


files 


function cails 


Serially reusable code, action program 


Shared code, action program 


SHDW command, UNIQUE 


Reference Page 


6.4 6-7 
9.4 9-8 
11 11-3 
6.5 6-18 
77 7-8 


See transaction 
routing. 


12 1-4 
71 7-2 
3.12 3-20 
10.2 10-2 
8.2 8-10 
8.6 8-22 
9.3 9-6 
6.5 6-18 
71 7-3 
71 7-1 
73 7-5 
7.2 7-4 
\ 
3] 3-8 
3.7 3-9 
13.3 13-3 


Term 


Shutdown 
definition 
IMS command (ZZSHD) 


IMS session 
modules, online processing 


Shuts down IMS command (ZZSHD) 


Simple transaction 


Single-line communications adapter (SLCA) 
Single message output, terminal 
Single-thread processing 
SNAP function call 
Snapshot dump feature 
Software package components, IMS 
description 
offline processing 
online processing 


pre-online processing 


Special output messages 


Standard terminal commands 


Startup, IMS session 

Startup modules, online processing 
STATFIL internal file 

Static terminals 


Statistical file print program, offline 
processing 


Status code, PIB 
Subschema module 


successor-id field, PIB 


index 11 


Reference 


5.3 
5.2 
6.4 
9.4 
5.2 
16 


6.4 
9.4 


12 
3.9 


2.3 
6.5 
13 
8.4 
8.4 
14 
17 
1.6 


15 


6.5 
6.2 
6.4 
9.4 
5.1 
16 
78 


6.1 


17 


75 


10.2 


3.11 
3.12 
3.13 


Page 


8-17 


6-18 
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Term Reference Page Term Reference Page 
Successor program 3.12 3-23 Terminal commands 
3.11 3-19 master 6.4 6-8 
3.13 3-24 remote transaction processing 9.4 9-8 
standard 6.4 6-6 
Supervisor, system generation 4.1 4-] 
43 4-4 Terminal control table, snapshot dump 8.4 8-19 
SUPGEN, system generation 4] 4-2 Terminal input editing 8.7 8-28 
Snapshot devices Terminal operations Section 6 
continuous output 8.1 
screen format services 8.6 8-22 Terminal processing, remote transactions 9.4 9-7 
Suspends output to terminal command (ZZHLD) 6.4 6-6 TERMINAL section, configuration 4.13 4-17 
9.4 9-8 
Terminal status display command (ZZTCT) 6.4 6-9 
Switched output messages 6.5 6-18 
Terminate IMS session command (ZZHLT) 5.2 5-3 
SWTCH ALL transaction code 6.4 6-14 6.4 6-8 
9.4 9-8 
SWTCH transaction code 6.4 6-13 
6.5 6-18 Termination, action program 3.9 3-13 
11.1 11-3 3.10 
3.11 
SYSRES, RESGEN phase 4] 4-2 
Termination codes 3.11 3-19 
System console 
input and output 6.6 6-21 Termination types 
master terminal commands 6.7 6-21 delayed internal succession 3.10 
restrictions 6.8 6-22 external succession 3.10 
standard terminal commands 6.7 6-21 immediate internal succession 3.10 
transaction processing 6.8 6-22 normal 3.10 a 
specifying type 3.9 
System generation (SYSGEN) 41 4-] 311 5 
Test mode, terminal state 6.3 6-5 
Test terminal status command (ZZTST) 6.4 6-9 
Thread control block, snapshot dump 8.4 8-19 
T Time frames, IMS software package 1.4 1-8 
TIMEOUTS section, configurator 4.13 4-17 
Tables, configuratgor 
action control table 3.8 3-11 TOMFILE internal file 7.8 7-10 
program control table 3.8 = 
transaction code table 3.8 3-11 TRANSACT section, configurator 6.4 6-10 
9.2 9-4 
Tape copy program, offline 17 1-14 
Transaction, action program 
Tape trace file 17 1-15 dialog 3.9 3-14 
7.10 7-12 simple 3.9 3-14 
7.12 7-14 
TERM macroinstruction 46 4-8 
6.1 6-1 
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& Term Reference Page Term Reference Page 
Transaction, complex example UNLOCK parameter 71 7-8 
BILL1 processing 3.14 3-30 
BILL2 processing 3.14 3-33 User-supplied action programs 1.6 1-14 
delayed internal succession use 3.14 3-32 
immediate internal successor use 3.14 3-30 UTS downline load feature 8.5 8-20 
processing menu selection 3.14 3-29 
program MENU processing 3.14 3-27 
Transaction code 
action program 3.8 3-10 
6.4 6-10 
batch processing 3.14 3-27 
11.1 11-1 
definition 1.2 1-2 
IMS 3.8 3-10 V 
sample 3.12 3-20 
table 3.8 3-11 Voluntary termination, action program 8.4 8-17 
Transaction code table 3.8 3-11 
Transaction control interface (TCI) 44 4-7 


Transaction facility, IMS 


configuration 9.2 9-4 
& Transaction routing Ww 
action program 9.1 9-3 
directory 9.1 9-2 Work area (WA) 23 9-5 
operator 9.1 9-3 35 3-5 
Transaction structure, creation 3.9 3-14 Working-storage section, COBOL/DML 10.2 10-3 
3.12 3-20 
3.14 3-27 
Transient load module 45 4-7 
TRACFILE internal file 7.8 7-9 
U 
UNIQUE (uniform inquiry update element) 
action programs 3.1 3-1 Zz 
applications 13.4 13-4 
batch transactions 111 11-2 ZCNF parameter, IMSCONF 4.12 4-16 
commands 13.3 13-3 
defined file creation 12.5 12-6 ZCHTRC offline recovery program 7.11 7-13 
12.6 12-13 7.12 7-14 
definition 1.2 1-4 
13.1 13-I ZEHCOPY (tape copy routine) 7.12 7-14 
file updating 76 7-7 
limitations 3.2 3-2 ZHHEDT (edit table utility) 48 4-11 
& LIST command response Fig. 12-8 12-11 
password creation 4-10 4-12 ZP#NRU (record file utility) 4.10 4-12 
12.6 12-9 
use 13.2 13-2 ZSTAT transaction code 6.4 6-13 





SPERRY <> UNIVAC 


USER COMMENT SHEET 


Your comments concerning this document wil! be welcomed by Sperry Univac for use in improving 
subsequent editions. 


Please note: This form is not intended to be used as an order blank. 





(Document Title) 





(Name of User) 





(Business Address) 


Fold on dotted lines, and mail. (No postage stamp is necessary if mailed in the U.S.A.) 
Thank you for your cooperation 


| 
| 
| 
| 
| 
| 
| 
| 
: Comments: 
| 
| 
| 
| 
| 
| 
| 
e| 
@: |. 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| From: 
| 
| 
| 
| 
| 
| 
| 
| 








| | | | NO POSTAGE 


NECESSARY 
IF MAILED 
IN THE 
UNITED STATES 


ino 





BUSINESS REPLY MAIL 


FIRST CLASS PERMIT NO. 21 BLUE BELL, PA. 





POSTAGE WILL BE PAID BY ADDRESSEE 
SPERRY UNIVAC 


ATTN.: SYSTEMS PUBLICATIONS 





P.O. BOX 500 
BLUE BELL, PENNSYLVANIA 19424 





